企业官网建设流程全解析

考研教资考资讯系统这类项目，正好卡在一个很有意思的位置：技术上足够一个全栈新手练手，业务上又有着非常明确的使用场景。我最近用Python负责后端，Vue写前端，在PyCharm里完成了这样一套系统。整个项目做下来，我觉得最有价值的不是某个页面写得多炫，而是从需求梳理、技术选型、编码落地到联调部署这条完整链路里踩过的那些坑、想明白的那些取舍。这篇文章就围绕这套系统，把我实际开发的过程和心得拆开讲清楚，目标是让正在学Python或者Vue的读者，看完能照着撸出一个属于自己的资讯系统。

1. 考研教资考资讯系统到底要做什么：需求拆解和功能地图

很多人一上来就急着写代码，结果做出来的东西四不像。我做这套系统之前，先把"资讯系统"这四个字拆分了三层。

第一层是内容。考研和教资考试有一个共同特点：信息来源极度分散。研招网的官方公告、目标院校的研究生院通知、各省教育考试院的教资报名文件、各种辅导机构的政策解读……这些信息分布在几十个不同域名，更新没有固定时间。咨询系统本质上解决的是"信息聚合+变化提醒"的问题，所以核心模块一定是分类管理、文章管理和推荐位管理。

第二层是用户。游客、注册用户、管理员，这三类人的需求截然不同。游客只看公开资讯，注册用户能收藏、能订阅分类、能评论问答，管理员要维护分类、发布文章、审核评论。我看到不少同类系统把用户模块砍掉了，只留下一个文章列表，那这就沦落成一个静态页面了，撑不起后面VueRouter动态路由和登录鉴权这些技术点。

第三层是数据关系。资讯文章可以挂在多个分类下（比如"考研数学"既可以属于"公共课"，也可以属于"数学专项"），所以用多对多关系比外键更合适。用户收藏和文章是典型的多对多且带额外字段（收藏时间），评论则是文章外键加用户外键。这些关系在关系型数据库里怎么设计，直接决定后面查询代码的写法。

我最终把功能地图圈定成这几块：

• 资讯前台：分类导航、文章列表（支持分页和关键词搜索）、文章详情、热门资讯排行
• 用户中心：注册登录、个人收藏夹、订阅的分类推送列表
• 后台管理：分类维护、文章发布（富文本）、评论审核、用户管理
• 附加能力：院校库和岗位库的基础查询（考研方向展示院校、教资方向展示招聘岗位）

这套功能范围对新项目来说不臃肿，又能覆盖Django/Flask后端几乎所有核心知识点，比如ORM关联查询、JWT登录、分页搜索、权限校验。前端的VueRouter、Axios请求、组件通信、插槽封装也都能用上。

2. 技术选型推演：django/flask的取舍、Vue版本选择和Pycharm定位

项目开篇前最难回答的问题就是：后端用Django还是Flask？我在做选型对比的时候，把三个框架放在一张表格里过了一遍。

这个项目是典型的"业务完整的系统"，所以我最后选择了Django。原因有三条：自带Admin后台对资讯管理来说太省事了，不用写一行代码就获得文章管理界面；Django ORM的查询语法在处理分类多对多、用户收藏筛选时比裸写SQL省心很多；Django的Auth用户体系和DRF配合做登录鉴权是现成方案。Flask不是不能用，但它把数据库、表单、权限这些都要自己组装，适合用来理解原理，不适合快速出成品。

顺带说一下FastAPI。如果这个系统只做纯API，未来还要接小程序端，FastAPI确实是更现代的选择。但FastAPI的异步特性和SQLAlchemy异步模式配合起来，对刚踏入全栈的开发者有一定心智负担，项目里如果还要写Admin后台又得额外引入第三方库，性价比在这个场景下不如Django。我的结论是：一个资讯系统用Django是稳妥路径，Flask版代码量少但组件拼装需要经验，FastAPI适合作为下一个阶段的进阶方向。

前端为什么选Vue而不是React？如果你主力语言是Python，Vue的模板语法更贴近后端开发者习惯——把一个Python函数拆成template的写法，上手速度明显比JSX快。版本上我选了Vue3，组合式API配合Vite的开发服务器热更新确实快，而且VueRouter已经迭代到第4版，动态路由、路由守卫这些API更干净利落。

至于PyCharm，我始终认为它是Python开发者的第一选择。很多人纠结社区版还是专业版，做前后端分离项目的话，社区版完全够用——创建虚拟环境、Git集成、Django模板识别、调试断点、SSH远程部署这些核心能力都不缺。专业版多出来的数据库工具和Docker支持属于加分项，等真有需要再考虑也不迟。

工具链的组合确定下来就是三条：后端Django、前端Vue3、IDE统一用PyCharm。接下来就是实操环节。

3. 后端实战：从建虚拟环境到资讯查询API落地（Django/Flask双版本要点）

3.1 虚拟环境、项目创建和第一轮配置

我习惯先创建一个独立的虚拟环境，不让项目的依赖和全局Python包混淆。终端里执行：

cd ~/projects mkdir exam_info_system cd exam_info_system python -m venv venv source venv/bin/activate # Windows是 venv\Scripts\activate pip install django djangorestframework django-cors-headers

然后创建Django项目和第一个app。这里有个习惯问题：项目名叫exam_info，app按照业务划分，我先建了一个叫info的app放资讯相关模型，又建了一个叫users的app放用户扩展信息。热词里经常出现"django创建app"，操作就是一行：

django-admin startproject exam_info . python manage.py startapp info python manage.py startapp users

settings.py里需要把Django、DRF、corsheaders还有两个新app注册进去。数据库初期用SQLite起步，因为零配置、文件即库，开发和测试阶段效率最高。等要真实部署了，再换MySQL或者PostgreSQL都不迟——Django的ORM会帮你屏蔽大部分迁移差异。语言和时区建议设置成：

LANGUAGE_CODE = 'zh-hans' TIME_ZONE = 'Asia/Shanghai' USE_TZ = True

这个时区设置在联调阶段尤其关键，后面我会专门说时间格式的坑。

3.2 数据模型设计：分类、文章、收藏和评论的关系

资讯系统的核心模型我设计成五个：

class Category(models.Model): name = models.CharField(max_length=50) parent = models.ForeignKey('self', null=True, blank=True, on_delete=models.CASCADE) is_active = models.BooleanField(default=True) class Article(models.Model): title = models.CharField(max_length=200) author = models.CharField(max_length=50) content = models.TextField() cover = models.ImageField(upload_to='covers/%Y/%m/', null=True, blank=True) category = models.ManyToManyField(Category, related_name='articles') tags = models.CharField(max_length=200, blank=True) view_count = models.IntegerField(default=0) publish_time = models.DateTimeField() created_at = models.DateTimeField(auto_now_add=True) class Favorite(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) article = models.ForeignKey(Article, on_delete=models.CASCADE) created_at = models.DateTimeField(auto_now_add=True) class Comment(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) article = models.ForeignKey(Article, on_delete=models.CASCADE) content = models.TextField() is_approved = models.BooleanField(default=False) created_at = models.DateTimeField(auto_now_add=True)

这里有几个值得说透的设计决策。第一个是Article和Category用ManyToManyField而不是外键，因为一篇数学复习经验文章可能同时归到"考研数学"和"备考经验"两个分类，单一的ForeignKey只能挂一个分类。第二个是Favorite表单独建，用户和文章是多对多，但收藏这个动作本身带有时间信息，所以拆成独立的中间模型，后面筛选"我的收藏列表"就能直接用过滤查询。

用PyCharm的Database工具看一下生成的表结构，你会发现Django自动为主外键建索引，多对多关系也自动生成了关联表，这些细节如果手写SQL很容易遗漏。模型写完执行：

python manage.py makemigrations info users python manage.py migrate

再把Admin后台的注册补上，第一版后台管理就成型了：

from django.contrib import admin from .models import Article, Category class ArticleAdmin(admin.ModelAdmin): list_display = ('title', 'author', 'publish_time', 'view_count') list_filter = ('category', 'publish_time') search_fields = ('title', 'content') admin.site.register(Article, ArticleAdmin) admin.site.register(Category)

3.3 序列化器、视图和查询的常见坑

DRF的序列化器负责把ORM对象转成JSON。我写法上倾向用 ModelSerializer，少写重复字段代码：

from rest_framework import serializers from .models import Article, Category class CategorySerializer(serializers.ModelSerializer): class Meta: model = Category fields = ['id', 'name', 'parent'] class ArticleListSerializer(serializers.ModelSerializer): category = CategorySerializer(many=True, read_only=True) class Meta: model = Article fields = ['id', 'title', 'author', 'cover', 'tags', 'view_count', 'publish_time']

视图层面用DRF的APIView或ViewSet。做资讯列表接口，我选择ListAPIView配合过滤后端：

from rest_framework import generics, filters from .models import Article from .serializers import ArticleListSerializer class ArticleListView(generics.ListAPIView): queryset = Article.objects.filter(publish_time__lte=timezone.now()).order_by('-publish_time') serializer_class = ArticleListSerializer filter_backends = [filters.SearchFilter, filters.OrderingFilter] search_fields = ['title', 'content', 'tags']

查询细节上最容易出错的是Django的延迟查询机制。queryset是惰性的，真正执行SQL是在序列化取值的时候。如果你在列表页把每篇文章的关联分类都序列化出来，会遇到一次典型的N+1查询问题：10篇文章会额外发10次查询分类的SQL。解决方式是用select_related和prefetch_related：

queryset = Article.objects.filter(...).select_related('author') \ .prefetch_related('category').order_by('-publish_time')

还有一个刚接触Django的人很容易踩的深坑：删除对象时用delete()方法。Django的delete()有两种行为，QuerySet的批量删除会直接走SQL删除，Model实例的delete()会先收集关联对象然后逐个删除。我在做收藏功能时就遇到过：删除用户时忘记处理他名下收藏的记录，结果触发了受限外键保护错误。批量删除的绕过方法是：如果你确定只要清空这个表的数据，最快的方式是：

Favorite.objects.all().delete()

但如果你要按条件删除关联数据，建议先用filter查询确认范围再删除，避免误伤。我调试时经常删除Article测试数据，发现连带的Favorite记录也被级联删除了——这是预期的，因为ForeignKey设了on_delete=models.CASCADE。

3.4 Flask分支版本的核心实现思路

如果非要用Flask来实现同样的后端，核心逻辑是等价的。Flask需要自己搭建SQLAlchemy和序列化层：

from flask import Flask from flask_sqlalchemy import SQLAlchemy app = Flask(__name__) app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///exam.db' db = SQLAlchemy(app) class Article(db.Model): id = db.Column(db.Integer, primary_key=True) title = db.Column(db.String(200)) content = db.Column(db.Text) view_count = db.Column(db.Integer, default=0)

Flask版本的优势是代码量小，整个项目的核心文件可能只有Django的一半。但你需要自己写分页解析、自己处理CORS中间件、自己设计序列化逻辑。我的建议是：学习阶段先用Flask把模型和视图跑通，理解HTTP请求到数据库查询的全过程，再切到Django就很容易理解它帮你做了什么。这个项目的表演阶段我用Django，但文中所有涉及查询、删除、关联的数据操作逻辑，在Flask的SQLAlchemy里几乎是一一对应的。

4. 前端实战：Vue环境配置、路由、资讯列表和详情页从零开始

4.1 Vue安装和环境配置的完整路径

前端部分的第一步是Node.js环境。很多人在这里踩坑，首要问题是版本：Vue3和Vite要求Node.js版本至少16以上，推荐装LTS稳定版。装完Node.js后自带npm，我喜欢用yarn或者pnpm管理依赖，这次用npm展示标准流程：

node -v # 检查版本 npm install -g @vue/cli # 传统方式 npm create vue@latest exam_info_frontend # Vue3+Vite方式 cd exam_info_frontend npm install npm run dev

如果你是PyCharm用户，可以在IDE终端里操作，也可以在Settings的Plugins里装Vue.js插件，让IDE识别.vue文件。我经常看到新人在Vue安装环节忘了npm install，直接运行，结果页面上全是"找不到模块vue"的错误——这个错太常见了，原因就是create vite模板文件下载完了但依赖没装。

npm install这个命令在Windows下偶尔会报node-sass相关的编译错误，这是因为某些老项目依赖node-sass需要本地编译工具链。Vue3官方模板已经不用node-sass了，用sass替代，或者干脆不用CSS预处理器，纯CSS起步完全够。

4.2 VueRouter配置、动态路由和导航守卫

前端项目的核心是路由规划。我设计的路由表分两块：公开路由和需要登录的路由。

// router/index.js import { createRouter, createWebHistory } from 'vue-router' const routes = [ { path: '/', component: () => import('@/views/HomeView.vue') }, { path: '/article/:id', component: () => import('@/views/ArticleDetail.vue'), meta: { requiresAuth: false } }, { path: '/favorites', component: () => import('@/views/FavoritesView.vue'), meta: { requiresAuth: true } }, { path: '/admin', component: () => import('@/views/AdminView.vue'), meta: { requiresAdmin: true } }, { path: '/login', component: () => import('@/views/LoginView.vue') } ] const router = createRouter({ history: createWebHistory(), routes }) router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else { next() } })

这里有一个很多教程没讲透的动态路由场景：管理员和普通用户的菜单结构不一样。比如普通用户不显示"评论审核"，管理员不显示"我的收藏"。两种实现思路——一是在模板里写v-if判断角色，二是用router.addRoute按角色动态挂载。我在这个项目里选择了后者，因为菜单项多了之后，动态路由能把权限配置和菜单渲染解耦：

const adminRoutes = [ { path: '/admin/articles', component: () => import('@/views/admin/ArticleManage.vue') }, { path: '/admin/comments', component: () => import('@/views/admin/CommentAudit.vue') } ] function setupAdminRoutes() { adminRoutes.forEach(route => { if (!router.hasRoute(route.name)) { router.addRoute('admin', route) } }) }

动态路由在权限系统中几乎是必用的：后端在登录接口返回这个用户的角色标识，前端拿角色决定路由集合。这套逻辑比v-if硬编码干净得多。

4.3 资讯列表页、详情页与Axios对接的完整流程

列表页代码逻辑比较标准：调接口拿数据、v-for渲染、翻页时重新请求。关键在于把请求逻辑收敛在api目录下，避免组件里散落一堆axios：

// api/article.js import request from '@/utils/request' export function getArticleList(params) { return request.get('/api/articles/', { params }) } export function getArticleDetail(id) { return request.get(`/api/articles/${id}/`) }

现在Vue生态里更推荐的写法是用组合式API封装一个useArticle的hook，把loading、data、error都收敛起来。不过在项目初期，直接用setup语法糖配合ref和onMounted也够清晰：

<script setup> import { ref, onMounted } from 'vue' import { getArticleList } from '@/api/article' const articles = ref([]) const loading = ref(true) const page = ref(1) onMounted(async () => { const res = await getArticleList({ page: page.value }) articles.value = res.data.results loading.value = false }) </script>

详情页要处理的核心问题有两个：富文本内容和视频音频。资讯系统的正文我保存的是HTML片段，前端直接v-html渲染即可。但有一个隐患：如果编辑器允许用户粘贴带样式的内容，v-html可能引入XSS风险。我在后端保存前用bleach类库做了白名单过滤，只保留p、h2、h3、img、ul、li等基础标签，这是资讯类系统必须做的安全加固。

4.4 组件插槽、内容折叠和视频PDF展示的处理细节

列表页里每篇资讯卡片封装成一个ArticleCard组件，这个组件里我重点用了Vue插槽。默认插槽放标题和摘要，作用域插槽放用户收藏按钮，具名插槽扩展标签区。插槽让我们在不改组件内部渲染逻辑的情况下，从外部注入任意内容，这是Vue组件组合的核心手段：

<ArticleCard v-for="article in articles" :key="article.id" :article="article"> <template #footer> <button @click="handleCollect(article.id)">收藏</button> </template> </ArticleCard>

长正文的阅读体验需要做内容折叠。我的做法是维护一个maxHeight变量，超过2000像素就截断，点击"展开全文"更新高度并隐藏按钮。这个折叠交互本质上是CSS文本溢出控制加动态类绑定，并不复杂，但如果没有的话长文页面显然不友好。

再往前一步，资讯文章里经常会内嵌PDF资料。这里有一个很多人误会的基础认知：img标签是不能直接显示PDF的。我在开发中试过直接用<img src="xxx.pdf">，结果是浏览器下载文件而不是渲染。正确方案有两个：轻量场景用iframe，重量场景用pdf.js库分页渲染。如果只想快速预览，iframe最简单：

<iframe :src="pdfUrl" style="width:100%; height:800px;"></iframe>

另外热词里提到的m3u8视频在资讯系统里也很常见——很多网课的录播流就是m3u8。Vue播放m3u8不用装任何额外浏览器插件，采用video.js配合HLS技术就能实现。播放器初始化的时候，检测到m3u8格式后走HLS.js的转换，整个过程是完全原生在网页里完成的。

5. 前后端联调最容易翻车的四个细节：跨域、时间、图片和富文本

5.1 跨域问题为什么会出现在前后端分离项目里

第一次跑通前后端联调的开发者，十有八九会在浏览器控制台看到这样的错误：CORS policy block...。原因是前端运行在localhost:5173，后端跑在localhost:8000，两个端口不同就构成了跨域。解决方案是给Django配置django-cors-headers中间件：

INSTALLED_APPS = ['corsheaders'] MIDDLEWARE = ['corsheaders.middleware.CorsMiddleware'] CORS_ALLOWED_ORIGINS = ['http://localhost:5173']

有个细节容易被忽视：CorsMiddleware要放在MIDDLEWARE列表尽量靠上的位置，文档明确说它优先于CommonMiddleware，因为跨域响应头必须在所有响应里存在。不按文档顺序放，某些视图会出现跨域头丢失。也可以用Vite的代理方案在开发环境绕过跨域，但生产环境仍然需要一个真正解决的方案，cors-headers是绕不开的一步。

5.2 时间时区问题：为什么前端查询显示永远差8小时

我踩过一个非常经典的坑：Django设置了TIME_ZONE='Asia/Shanghai'，前端拿到的publish_time却还是UTC时间。原因是USE_TZ=True时，Django存进数据库的时间是UTC的，序列化器输出时会按照UTC格式输出，带一个尾缀Z。前端直接new Date是没问题，但如果你直接当字符串展示，就会差8小时。

处理方式我推荐在序列化器里做强制格式转换：

class ArticleListSerializer(serializers.ModelSerializer): publish_time = serializers.DateTimeField(format='%Y-%m-%d %H:%M', read_only=True)

这样前端拿到的就是"2025-03-01 09:30"这种直接可展示的字符串，省去前端时间库的格式转换。如果你要在前端做"相对时间"展示（比如"3分钟前"），那还是用ISO标准时间字符串更合适。这里的本质是：定义好API的时间契约，前端按契约解析，不要在前后端各处理一次时区。

5.3 图片路径拼接和后端Media文件的正确配置

资讯封面图返回给前端的字段是相对路径，比如/covers/2025/03/01/xxx.jpg。如果前后端不在同一台服务器，前端拿这个路径去拼接API域名是必要的。我在ImageField上传后，用request.build_absolute_uri来生成完整URL：

class ArticleDetailSerializer(serializers.ModelSerializer): cover = serializers.SerializerMethodField() def get_cover(self, obj): if obj.cover: request = self.context.get('request') return request.build_absolute_uri(obj.cover.url) return None

同时别忘了在settings.py里配置MEDIA_URL和MEDIA_ROOT，并在主路由里开发阶段加上media文件的服务。生产部署时这一步由Nginx接管。

5.4 富文本编辑器的选型和内容安全

后台发文章必然会用富文本编辑器。我试过几款知名的开源编辑器，最后选了和Vue配合较顺的组件，核心原因是它有图片上传的回调接口，能直接传到自己后端的接口并返回可访问的URL。富文本保存下来的HTML内容，前端渲染前必须经过过滤，这一点我在项目正式上线前专门花时间加固过：图片标签的src必须白名单域名、script标签一律移除、onclick等事件属性全部剥掉。这些细节如果偷懒不做，系统被人发一篇带恶意脚本的文章，用户打开就中招了。

6. 上线前的收尾工作：Pycharm调试技巧、部署检查清单和性能优化

6.1 Pycharm调试的核心经验和AI插件配置

联调阶段我把PyCharm的调试功能吃得很透。除了在代码左边点击行号设置断点，我还常用条件断点——在断点图标上右键，设置表达式只有view_count大于200才暂停。这在排查点击量暴增问题时特别有效，不用一遍遍手动触发。

PyCharm的Run/Debug Configurations也值得仔细配置：Environment variables里设置DJANGO_SETTINGS_MODULE指向测试环境配置，Working directory指定到项目根目录。这一步没配好，经常会出现能正常runserver但Debug启动就报ModuleNotFoundError的诡异问题。

现在PyCharm的插件市场里有不少AI辅助编码插件，补全和代码解释能力确实能帮上手者提速。我的使用习惯是把它当"更聪明的自动补全"用，而不是无脑接受它给的代码逻辑——尤其是ORM查询这类业务代码，机器生成贴合的上下文仍然有限，最终的理解责任还是要自己承担。

6.2 部署检查清单：从DEBUG开关到静态文件收集

本地跑通不代表能上线。我整理了一份自己的部署前检查清单，执行顺序很重要：

• settings.py的DEBUG切到False，ALLOWED_HOSTS写入真实域名
• 生成Django SECRET_KEY并存入环境变量，别写死在代码里
• 收集静态文件：python manage.py collectstatic，并配置STATIC_ROOT
• 数据库备份一次，执行makemigrations后再迁移一次
• 用gunicorn启动应用，配合反向代理处理静态文件

Flask部署流程类似，但WSGI服务器推荐用gunicorn或者uwsgi，生产上别用自带的开发服务器。如果你用的是Django，gunicorn的启动命令我习惯写进一个脚本里：

gunicorn exam_info.wsgi:application -w 4 -b 127.0.0.1:8000

后面再接Nginx反向代理。这个部署模式对中小型资讯系统已经足够了。

6.3 查询性能和接口体验优化

上线前的压测暴露出几个明显的性能瓶颈。第一个是首页列表接口：一次请求返回了20篇文章，每篇都附带分类和作者信息，N+1查询直接导致响应时间翻了几倍。解决方式就是前面说的select_related和prefetch_related，这个优化代码只改几行，性能提升立竿见影。

第二个是浏览量自增的写法。新手容易写成：

article = Article.objects.get(id=article_id) article.view_count += 1 article.save()

这样有两个问题：先读后写有并发覆盖风险，而且两条SQL才能完成。正确方式是Django自带的F表达式：

Article.objects.filter(id=article_id).update(view_count=F('view_count') + 1)

F表达式会让SQL直接在数据库层完成自增，并发安全且只发一条语句。

第三个是热门资讯排行榜的缓存。我把首页排行榜做了10分钟的本地缓存，用Django的cache框架，配置成LocMemCache。对单机部署的小型系统，这个方案零额外依赖，效果却非常明显。如果以后并发真上来了，再切换到Redis即可。

资讯系统最后一个体验优化点是分页。DRF默认的LimitOffsetPagination，或者PageNumberPagination都能用，我选了PageNumberPagination，同时在前端列表底部做成"加载更多"按钮，而不是传统的页码条——资讯流这个场景里，"加载更多"的手感明显好于翻页。

整套项目从需求到部署走完，我最大的感受是资讯类全栈系统非常适合作为第一个独立项目：业务规则不复杂，但又能天然覆盖用户系统、内容管理、检索、权限、前后端联调这些通用模块。你在跟着复现的过程中，把Django的ORM和Vue的组件通信吃透，后面再去做电商、教育、小程序后端，会发现很多套路是完全相通的。最后再分享一个实际开发中的小习惯：后端接口的返回结构我在项目开始就定死了，统一是{code, message, data}，前端Axios请求拦截器统一处理code非200的情况，避免每个页面重复写错误弹窗。前后端契约先定清楚，联调阶段的沟通成本会低很多。