最近把之前做的在线教育平台重构了一遍前后端分别试过 Django 和 Flask 两套后端方案前端用 Vue 重写全程在 PyCharm 里开发。这个项目从课程管理、学习计划到师生互动功能不算复杂但真正落地时踩了不少坑。今天把整个复盘整理出来从技术选型、表设计、接口规范到联调排查一次性说清楚给正在做类似系统的人一个参考。1. 平台要做什么技术栈怎么选1.1 需求拆解学习计划、师生互动、课程管理在线教育平台市面上很多但大多只解决了“看视频”这一个需求。我这次的目标很明确做一个真正能辅助教学的平台核心落在学习计划和师生互动上。拆解下来平台要覆盖三类用户角色学生浏览课程、观看视频、制定学习计划、提交作业、在讨论区提问。教师上传课程内容、布置学习任务、批改作业、回复学生提问、发起讨论话题。管理员审核课程、管理用户、统计平台数据。其中学习计划不只是学生在文档里记个目标而是要有真正的“计划—执行—反馈”闭环教师可以创建阶段性任务学生按周期完成任务并标记进度系统自动记录完成情况。师生互动则包含两个层面同步的站内私信和异步的问答讨论区。这个需求决定了系统必须有清晰的角色权限模型、内容管理能力和消息机制技术选型也必须围绕这几块展开。1.2 Django还是Flask我的选型逻辑和对比后端框架我两套都写过这里直接说结论如果你要做完整的平台首选Django如果只是做轻量API或者想快速验证原型选Flask更灵活。两者的差异非常直观维度DjangoFlask定位全功能大而全框架轻量微框架ORM内置模型定义后直接迁移需自行集成SQLAlchemyAdmin后台内置改配置就能用需要自己写认证系统自带User模型和权限体系自己搭或接JWT适合场景完整业务系统、后台管理纯API服务、快速原型我实际开发中的体感是用Django做后台管理非常爽——用户、课程、计划这些数据模型定义好后Admin后台几乎白送但Django的“重量感”也明显中间件、app结构、settings配置新手容易被绕晕。Flask则自由得多一切从零搭建适合动手能力强的人但权限、ORM都要自己选型接上工程一复杂就容易写乱。这里的核心建议是选框架不是在比谁强而是看你的项目规模和团队习惯。项目里有多张关联表、有后台管理、有权限体系Django能帮你省一半工作量项目以API接口为主前端全包装完了Flask反而更轻巧。1.3 前端为什么选Vue加Element Plus前端技术选型时我对比过React和Vue。React的生态更成熟但对团队入门门槛稍高Vue的模板语法直观组件化开发体验顺滑配合Element Plus组件库能快速搭出后台管理界面。这个平台里前端的工作量集中在课程后台、学习计划看板、师生交流页面属于典型的中后台系统——这种场景Vue加Element Plus非常合适。Element Plus提供的表格、表单、日期选择器、分页组件直接省去手写UI的时间我大概估算了一下至少提效40%。Vue 3的组合式API让逻辑复用也更方便。比如不同页面都要做“当前用户”判断抽成一个useAuth组合函数每页调用即可。无论你是Vue新手还是从Vue 2迁移过来这套组合式写法都值得好好掌握。2. 后端核心设计从数据表到API接口2.1 用户模型与角色权限设计用户是平台的基石权限设计直接影响整个系统的安全性和易用性。我用Django自带的User模型扩了一个Profile表存角色字段student、teacher、admin。需要说明的是Django默认的用户表只解决“登录认证”具体业务角色需要自己扩展。我选的方案# models.py from django.contrib.auth.models import AbstractUser class User(AbstractUser): ROLE_CHOICES ( (student, 学生), (teacher, 教师), (admin, 管理员), ) role models.CharField(max_length20, choicesROLE_CHOICES, defaultstudent) real_name models.CharField(max_length50, blankTrue) avatar models.URLField(blankTrue)这里有个决策细节为什么不直接建三张独立的用户表因为三张表会导致登录逻辑分散、外键关联混乱后续扩展消息、课程关系都要反复判断用户类型。一份用户表加角色字段才是常规且好维护的方案。API层面我配了JWT认证JSON Web Token登录后返回access_token和refresh_token。前端拿到token后保存在本地存储每次请求带在Authorization请求头里。后端再用Django REST framework的IsAuthenticated作为基础权限用自定义IsTeacher、IsStudent做角色校验。这部分的经验是别自己在Django里裸写Token认证直接用djangorestframework-simplejwt省力且安全。我最初想自己生成签名踩了刷新逻辑的坑后来换掉。2.2 课程与学习计划的数据模型课程和学习计划是核心业务表设计直接决定系统能不能支撑“学—练—测”闭环。课程模型我拆成三级Course课程、Chapter章节、Lesson课时视频文件挂在Lesson上。加章节层的好处是后续要支持“按章节解锁”、“章节测验”时可以不动主表结构。学习计划则是这个平台的差异化功能。我设计了两个核心表class StudyPlan(models.Model): student models.ForeignKey(User, on_deletemodels.CASCADE, related_nameplans) course models.ForeignKey(Course, on_deletemodels.CASCADE) title models.CharField(max_length200) start_date models.DateField() end_date models.DateField() class PlanTask(models.Model): plan models.ForeignKey(StudyPlan, on_deletemodels.CASCADE, related_nametasks) lesson models.ForeignKey(Lesson, on_deletemodels.CASCADE, nullTrue, blankTrue) title models.CharField(max_length200) complete_by models.DateField() is_done models.BooleanField(defaultFalse)StudyPlan是一份计划PlanTask是计划中的具体任务。为什么任务要单独建表而不是在计划里塞JSON因为任务要支持逐个标记完成、按日期筛选、教师查看进度汇总独立成表才能用数据库查询高效解决。这个设计思路和Trello看板的“卡片”很像一份计划就是一块看板每个任务是看板上的卡片。学习计划页面的核心交互就是学生查看任务列表点击“标记完成”系统更新is_done字段前端通过计划详情接口实时刷新进度条。这个功能界面不炫但数据模型一旦设计清楚前后端写起来都非常顺。2.3 师生互动的消息与问答设计师生互动我拆成三个模块问答讨论区、作业提交、站内私信。三者的数据特征不同设计上分开放。问答讨论区类似论坛的简化版class Question(models.Model): course models.ForeignKey(Course, on_deletemodels.CASCADE) user models.ForeignKey(User, on_deletemodels.CASCADE) title models.CharField(max_length200) content models.TextField() created_at models.DateTimeField(auto_now_addTrue) class Answer(models.Model): question models.ForeignKey(Question, on_deletemodels.CASCADE, related_nameanswers) user models.ForeignKey(User, on_deletemodels.CASCADE) content models.TextField() created_at models.DateTimeField(auto_now_addTrue)这个设计了两个表理由是因为问答是一对多关系问题下面有多条回答。很多新手会把回答做成一个字段塞在问题表里查询时再解析这是我强烈建议避免的做法——不仅查询慢后续要做“最佳答案点赞”等功能时根本没法维护。作业提交模块我用了Assignment教师布置和Submission学生提交两张表学生提交内容存file_url和text_content教师提交批改的grade和comment。站内私信则单独建Message表记录sender、receiver、content、is_read。这三个模块看起来零散但本质上都是“内容生产—权限控制—通知触达”的模式明白这个模式后任何互动功能你都能套用。2.4 API接口的规范与认证方案API设计完全遵循RESTful风格资源用名词复数操作通过HTTP动词表达GET获取、POST创建、PUT更新、DELETE删除。举个例子学习计划相关的接口方法路径功能GET/api/plans/获取当前用户的学习计划列表POST/api/plans/创建学习计划GET/api/plans/{id}/获取计划详情及任务列表PUT/api/plans/{id}/修改计划信息DELETE/api/plans/{id}/删除计划PATCH/api/tasks/{id}/标记任务完成统一接口规范的好处是前后端联调时心智负担小。前端只需要知道“资源”和“动作”不需要记一堆风格各异的接口名。认证方面JWT是目前前后端分离项目的标配。Django下用djangorestframework-simplejwt安装后配置SIMPLE_JWT里的过期时间即可。我的配置SIMPLE_JWT { ACCESS_TOKEN_LIFETIME: timedelta(minutes30), REFRESH_TOKEN_LIFETIME: timedelta(days7), }注意这里的细节ACCESS_TOKEN_LIFETIME不要设置太长。我之前设成1天用起来确实方便但安全风险大——前端XSS一旦窃取token攻击者能操作一天。30分钟刷新一次体验和安全之间是比较好的平衡。3. 前端Vue实现页面组件与交互3.1 Vue环境搭建与工程结构Vue 3的环境搭建现在用官方脚手架create-vuenpm create vuelatest过程中会让你选要不要TypeScript、Vue Router、Pinia等按需选择即可。如果没装Node.js先去官网下载LTS版本——务必选LTS长期支持版开发体验远好于Current版本。装好后建议装几个基础依赖npm install element-plus npm install axios npm install pinia npm install vue-router4工程结构我按模块功能拆分而不是单纯按文件类型堆砌src/ api/ # 接口请求封装 assets/ # 静态资源 components/ # 公共组件 router/ # 路由配置 stores/ # Pinia状态 views/ Course/ # 课程模块页面 Plan/ # 学习计划页面 Interact/ # 师生互动页面 User/ # 用户相关页面这样设计的好处是开发某个模块时上下文集中比如改学习计划时只需要看views/Plan和对应的api/userPlan.js不用在几十个散落的文件里乱翻。3.2 路由、权限拦截与状态管理前端路由用Vue Router页面按角色区分。核心的实现是路由守卫——判断用户登录状态和角色决定是否允许访问某个页面。// router/index.js router.beforeEach((to, from, next) { const authStore useAuthStore() if (to.meta.requiresAuth !authStore.isLoggedIn) { next(/login) } else if (to.meta.role authStore.user.role ! to.meta.role) { next(/403) } else { next() } })这段逻辑对应三个页面类型无需登录登录注册页、需登录学习计划、需特定角色教师后台。路由元信息里配置requiresAuth和role守卫统一判断。这里有个实际体验把“是否登录”状态放在Pinia里但初始化时要向后端请求一次用户信息。我曾经只存token不存用户信息刷新页面后Pinia清空导致守卫判断失败用户莫名被踢回登录页。后来每次页面刷新都在App.vue的onMounted里重新拉取用户信息问题才解决。状态管理方面我建了三个storeauthStore管理用户信息planStore管理当前学习计划及任务messageStore管理未读消息数。Pinia的写法很简洁一条defineStore就能完成。3.3 学习计划页面的组件实现学习计划页面是整个平台前端比较考验组件拆分能力的部分。我的实现思路是三层父组件PlanBoard.vue负责拉取计划数据、加载状态、分发数据给子组件。子组件PlanHeader.vue显示计划标题、起止日期、总进度条。子组件TaskList.vue渲染任务列表每个任务带“标记完成”按钮。核心交互是点击“标记完成”。前端实现async function toggleTask(task) { task.is_done !task.is_done try { await updateTask(task.id, { is_done: task.is_done }) } catch (error) { task.is_done !task.is_done // 失败回滚 ElMessage.error(更新失败) } }这个实现里有个很细节但极其重要的体验处理乐观更新。就是先改前端状态、再调接口、失败就回滚。相比“先调接口转圈成功了再改UI”乐观更新让用户感觉几乎零延迟交互大幅提升体验。进度条直接用一个计算属性const progress computed(() { const total tasks.value.length if (total 0) return 0 const done tasks.value.filter(t t.is_done).length return Math.round((done / total) * 100) })这种简单的小逻辑用Vue的组合式API写非常顺手不依赖插件不用后端计算前端拿到任务列表后自己算就行。3.4 师生互动模块的实时交互师生互动中的问答讨论区我用的是Vue加axios轮询的方式实现——前端每10秒拉取一次最新回答。为什么用轮询而不是WebSocket因为问答讨论区不是聊天室对实时性要求没那么高。10秒内刷新出别人的新回答体验已经足够好。WebSocket虽然更“高级”但会引入连接管理、断线重连、消息持久化一堆复杂度对于这个场景是杀鸡用牛刀。轮询的实现const loadAnswers async () { const res await getAnswers(questionId.value) answers.value res.data } onMounted(() { loadAnswers() timer setInterval(loadAnswers, 10000) }) onUnmounted(() { clearInterval(timer) })注意这里的细节onUnmounted必须清理定时器否则页面切走了还在轮询浪费请求资源。这是我调试时发现的典型问题——切到别的页面后浏览器Network面板里还有源源不断的请求。站内私信部分我用了一个相对轻量的方案消息列表进入时加载发消息后立即追加到前端数组轮询只更新“未读数量”这个轻量数据。这就在不引入重型技术栈基础上兼顾了实时感和性能。4. PyCharm下的开发调试与联调4.1 Django项目在PyCharm中的配置PyCharm是我整个开发过程中最重要的工具没有之一。它对于Django和Vue项目的支持都很完善几个关键配置做对后效率提升非常明显。首先配置Django支持。在PyCharm里打开项目后File - Settings - Languages Frameworks - Django勾选Enable Django support指定项目的settings.py路径。配置好后Run窗口里可以直接用的manage.py命令模型字段跳转、模板语法提示都能正常工作。其次配置Python解释器。建议创建虚拟环境venv或conda然后在PyCharm里把项目解释器指向它。虚拟环境的好处是依赖隔离——不同项目用不同包版本不会互相干扰。我见过太多人因为全局环境装包而出现版本冲突一查全是小白必经的问题。然后配置运行配置。顶部运行配置选Django Server设置好host127.0.0.1、port8000。注意调试时勾选Debug模式启动Django的自动重载改代码保存后自动重启不用手动反复启停。Vue项目则在PyCharm里直接配置npm运行。我习惯在PyCharm的Terminal面板里执行npm run dev因为前端报错输出带颜色定位问题方便。PyCharm的Terminal面板集成了前端工具的快捷键提示体验不比独立的编辑器差。4.2 接口调试与数据库迁移联调阶段最重要的工具是PyCharm的HTTP Client——自带的接口调试工具比Postman轻量。直接在项目里建一个.http文件像这样### 获取学习计划列表 GET http://127.0.0.1:8000/api/plans/ Authorization: Bearer {{token}} ### 标记任务完成 PATCH http://127.0.0.1:8000/api/tasks/3/ Content-Type: application/json Authorization: Bearer {{token}} { is_done: true }用.http文件的优势是可以把接口请求放进版本管理里和后端代码一起维护。后端改了字段前端看一眼.http文件就知道现在接口长什么样沟通成本大幅降低。数据库迁移这块Django的三步走是固定的makemigrations生成迁移文件migrate执行迁移showmigrations查看迁移历史。我遇到字段变更时总有人忘了执行makemigrations直接改表导致不一致。记得PyCharm里也有这个命令的面板提示但用命令行最稳妥。需要特别注意的是迁移文件不要手删。我一度觉得迁移文件没用直接删掉重新生成结果数据库状态对不上只能重建库。正确做法是保留迁移记录走正规的迁移流程。4.3 前后端联调的常见坑联调是最容易出问题的阶段我梳理几个高频坑坑一跨域。前端跑在5173端口后端跑在8000端口不同源。Django需要处理CORS用django-cors-headers这个库INSTALLED_APPS [ # ... corsheaders, ] MIDDLEWARE [ # ... corsheaders.middleware.CorsMiddleware, # ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, ]只配置CORS_ALLOWED_ORIGINS而不用CORS_ALLOW_ALL_ORIGINSTrue是为了避免完全开放的跨域这是安全底线的考量。坑二请求体格式不一致。前端axios发送application/json格式Django端必须用djangorestframework的解析器解析JSON。我第一次写接口时直接裸request.POST.get(title)取参数结果数据一直是空——因为POST请求不是表单格式。后来统一用DRF的Request对象才解决。坑三时间格式。前端组件库的日期选择器默认输出YYYY-MM-DDDjango的DateField接收没问题但如果前端把日期存成了时间戳后端就要做转换。我统一在Django的序列化器里做格式化输出保证前端拿到的永远是YYYY-MM-DD把复杂性收束在后端。坑四图片和文件上传。Media文件默认只有debug模式下Django能提供访问线上必须配置独立存储。我在开发环境踩过上传了图片但前端访问不到的问题后来在settings.py里配置了MEDIA_URL和MEDIA_ROOT开发时用static服务托管线上一律转对象存储。5. 上线前后必踩的坑问题排查实录5.1 Vue环境安装和依赖问题的排查Vue项目环境安装出问题的概率极高尤其是新手。最常见的是Node版本太老导致依赖安装失败。我遇到过npm install报ERR_OSSL_EVP_UNSUPPORTED一查是Node 17之前版本的OpenSSL兼容问题简单解法是升级Node到18或者用NODE_OPTIONS--openssl-legacy-provider临时绕过。还有Element Plus按需引入时unplugin-vue-components插件配置容易漏了ElementPlusResolver导致组件样式丢失。排查方法是打开浏览器控制台看有没有“style not found”的报错提示。别问我为什么知道——都是实际踩过的。依赖版本冲突也很常见。我建议在项目初始化时就锁定package-lock.json不要用npm install频繁更新依赖有时候一个主版本升级整个组件的API接口都变了排查成本很高。5.2 视频播放与文件上传的细节在线教育平台绕不开视频。我的方案是把视频文件传到对象存储直接拿到CDN加速的播放地址前端用H5的video标签播放。为什么不用自建视频服务器因为带宽成本、转码成本、防盗链实现都是大工程非核心竞争力的功能不值得投入对象存储加CDN足够支撑大部分场景。视频加密是行业里绕不开的话题但我要劝你冷静不要把精力花在绝对安全的视频加密上而是花在“播放体验”上。花哨的加密方案成本高、体验差且仍有破解风险。平台的护城河是课程质量、互动体验和数据不是防破解技术。文件上传这一块我的经验是后端不直接收文件流而是发一个预签名URL。前端先把文件传到对象存储再把文件的地址提交给后端。这样能大幅降低后端服务器的带宽和存储压力。实现上Django端用一个接口生成预签名URL即可。5.3 数据库查询的性能优化和安全管理当课程数量多起来后一个经典的性能问题会暴露N1查询。比如获取学习计划列表时每个计划都要查一次课程信息计划多时请求次数线性上涨。Django ORM的select_related能解决这个问题plans StudyPlan.objects.select_related(course).filter(studentrequest.user)这样一条SQL就能把关联的课程信息取出来避免N1。这个优化在大数据量下非常明显我优化后接口响应时间从约900毫秒降到约120毫秒。安全方面要盯几个点密码存储Django自带make_password加盐哈希不要自己写明文存储。接口防抓取对公开接口做频率限制用django-ratelimit之类库实现。XSS防护前端渲染问答内容时转义HTML标签别用v-html直接渲染用户输入。SQL注入ORM已经帮你规避了大多数注入风险但如果你写了原生SQL务必要用参数化查询。还有一点容易被忽略敏感信息不要暴露在接口响应里。用户序列化时密码字段、邮箱联系方式这类信息一定勾选write_only只允许写入不允许读取。5.4 部署阶段的常规流程和容器化方案部署我采用前后端分离的方式前端Build成静态文件部署到Nginx后端用Gunicorn加Django跑在服务器上数据库用独立部署的MySQL或PostgreSQL。Django的部署前检查主要集中在python manage.py collectstatic python manage.py check --deploycollectstatic收集静态文件到统一目录check --deploy会检查部署环境中的安全问题比如DEBUG模式是否关闭、ALLOWED_HOSTS是否配置。这两步一定要跑不然线上会踩各种奇奇怪怪的坑。容器化方案上我用Docker Compose编排后端、前端、数据库三个服务。前端Nginx里配置反向代理把/api路径的请求转发到后端容器这样前端代码里可以直接用相对路径请求接口省去跨域配置。这个方案的好处是部署简单环境一致性高。### 5.5 学习计划模块的权限边界处理 关于学习计划有个之前提到但值得单独展开的细节**计划归属权问题。** 学生创建的学习计划教师是否可以修改我的答案是学生是计划的创建者和执行者拥有完整的增删改权限教师拥有“查看”和“布置任务”的权限但不能删除学生已创建的日程。 我在后端序列化器里做了权限校验 python class PlanSerializer(serializers.ModelSerializer): class Meta: model StudyPlan fields __all__ read_only_fields (student,) def validate(self, data): user self.context[request].user if user.role ! student and self.instance is None: raise serializers.ValidationError(仅学生可以创建计划) return data这样设计逻辑很直白平台是“以学生为中心”的学习计划是学生自己的安排教师可以引导和督促但不能越俎代庖随意修改。这个边界如果一开始不划清楚后面生产环境里会出现大量权限相关的反馈工单。前端这边如果是教师查看学生计划页面上就不渲染“编辑”和“删除”按钮只显示“查看详情”和“布置任务”。通过v-ifauthStore.user.role teacher来控制。实际开发中的几点心得项目从前到后完整走了一遍技术上整体不算难但很多细节积累下来非常宝贵。总结几个自己的心得体会框架选型要放到具体业务里去评判。如果我只是做一个展示型项目Flask完全够用但要做课程管理、学习计划、消息系统、作业批改这种多实体关联的系统Django能在数据建模和Admin后台方面节省大量重复劳动。不是Django比Flask好而是Django更匹配这个业务场景。数据模型设计决定了系统的上限。学习计划如果不单独建任务表后面做进度统计、教师督查、日历视图都无从下手。这个项目里最有价值的设计决策就是把计划拆成“计划”和“任务”两层后面所有功能都受益于这个决定。前后端联调最浪费时间一定要用规范对齐。我强烈建议后端先把.http接口文档文件写清楚前端先按文档开发而不是边开发边问“这个字段是什么”。双方都按规范输出联调从“排错模式”变成“验证模式”效率完全不同。重视乐观更新和失败回滚。这是高端体验和普通体验的分水岭。一个“标记完成”操作转圈1秒再更新和瞬间更新失败回退体感差距非常大。这种细节不必每个地方都用但在高频操作上一定要实现。学习计划模块值得继续扩展的方向。比如日历视图展示任务分布提醒通知到站内信或邮箱教师端批量布置同课程任务学生端统计学习时长和完成率曲线课程推荐基于学习计划当前进度。这些功能的技术基础——数据模型和接口规范——已经打好后续扩展只是往上面叠加功能的问题。这个项目目前已经稳定运行。如果你正在做同类型的在线教育或培训系统希望这篇复盘能帮你少走一些弯路。如果有什么问题欢迎在评论区交流。