毕设做到一半你会发现最难的不是写代码而是搞清楚“这门课到底要我做出来个什么东西”。尤其是“在线学习平台”这种题目听起来谁都能做、满大街都是但真要交出去又要能跑、又要有文档、又要答得上答辩老师随口一句“这个权限是怎么控制的”就麻烦得很了。这篇文章我就以一套实际交付过的Django在线学习平台为例把从技术选型到用户权限、从业务表设计到视频播放、从代码讲解到部署上线的完整链路拆开讲一遍。不是给那种“点个按钮生成项目”的教程而是把每个设计决策背后的理由和踩过的坑都交代清楚适合正在做毕设、或者想在公司内部快速搭一套轻量培训系统的同学参考。1. 为什么在线学习平台用Django做是最稳的选择1.1 毕设场景下Django对新手最友好的地方先聊一个很多人纠结过的问题Java的SpringBoot、前端的Express/Nest、Python的FastAPI和Django之间到底选谁做毕设最保险。我的结论很直接如果是单人开发、时间三个月以内、需要完整交付文档和代码讲解Django是性价比最高的方案。原因有几点。第一Django自带Admin后台。这意味着“管理员管理课程、管理用户”这类需求几乎不用写代码就能搞定自动生成的表单、列表、筛选、搜索功能对着文档几分钟就能上手。这个优势在SpringBoot里对应的是代码生成器在FastAPI里干脆没有得自己写前端。对一个以“设计和实现”为主题的毕设来说内置Admin可以实打实省出两周时间。第二Django的ORM比SQLAlchemy更接近“一学就会”的体验。外键关联、多对多关系、联表查询在Django里都对应成Python类的字段定义写起来直观查起来也顺手。以课程和章节的关系为例模型里定义为外键页面里用句点号就能把关联数据取出来不用手拼SQL。这一优势在赶进度的时候特别明显。第三Django的Model-View-Template框架虽然老但它是教科书级的MVC思路。写进毕业设计论文里的“系统架构设计”章节几乎可以把项目的app目录结构直接映射成文字不需要额外包装。1.2 三个热门替代方案的取舍分析我不是说其他框架不行而是想帮你把选择时容易忽略的成本摊开来看。如果选SpringBoot你得先熟悉Maven依赖管理、配置文件这些基础设施然后面对JPA或者MyBatis两种持久层方案。对没有Java Web经验的人来说光是把环境搞定可能就要一周这还谈不上写业务。如果选FastAPI优势是异步性能和自动生成API文档但劣势也很现实毕设题目是“平台的设计与实现”通常要求有页面展示。FastAPI本身不适合直接渲染服务端页面你还是得搭配Vue或者其他前端框架等于一个人做两个人的活。如果选Flask它足够轻但又不全——Admin、ORM、表单验证、登录会话这些组件在Django里是集成的在Flask里则要一个个挑选插件。选插件也是时间成本。综合下来在线学习平台这种“功能偏传统、注重管理后台、需要多页面”的题目Django既不会让你在架构上过度纠结又能保证写出来的代码能支撑一场合格的答辩。2. 先分清三种用户角色再动笔写表结构2.1 学生、教师、管理员三端的核心功能边界平台的第一版需求其实不需要多花哨老老实实做三端就够了。管理员端功能包括用户管理、课程分类管理、课程审核、数据统计。教师端功能包括创建课程、管理课程章节、上传视频、布置作业、批改作业、发布公告。学生端功能包括浏览课程、报名课程、在线观看视频、查看资料、提交作业、参与课程问答。这三类角色的边界一定要在写模型之前理清楚因为后面所有的权限控制、页面跳转、菜单显示全都依赖这个边界。常见的返工就是“教师能不能审核课程”这类问题没想好就动手写页面最后改来改去很痛苦。2.2 关键的模型设计用户、课程、章节、作业怎么做关系模型设计是整个项目的脊梁。我的习惯是先画一张关系图——不画那种复杂UML就是手写几个方框和连线确认每个模型的外键指向谁然后在Django里落地。用户模型方面虽然Django提供了内置的User模型但建议从一开始就创建自定义的User模型继承AbstractUser额外加上手机号、头像、角色、简介等字段。自定义User模型一定要在第一次执行数据库迁移之前做否则中途切换会非常麻烦。课程模型必须有标题、封面、简介、所属分类、创建教师、价格、是否上架、创建时间、更新时间。这里要特别注意“创建教师”字段和“是否上架”字段前者对应后面所有课程列表的过滤条件后者对应前端页面的展示逻辑。章节模型最简单课程、章节序号、标题、视频文件、视频时长、是否免费。这里有一个很实用的设计一个课程下的第一节或者前几节设为免费试看让学生不登录就能看到一定内容对整个平台的体验和转化都有帮助落到表里就是一个Boolean字段。作业模型要考虑到“教师布置、学生提交、教师批改”这三个阶段因此作业主表存放作业标题和要求提交表存放学生上传的文件地址、提交时间和得分一个学生可以提交多次作业取最后一次或者最高分作为最终成绩具体取法在表单里设定。这种设计在Django里实现成本不高但功能完整性立刻上一个档次。视频模型不用单独建直接挂在章节里用FileField存视频文件路径就行。2.3 在线答题和笔记模块的取舍与实现很多同学第一眼看到“在线学习平台”就会想把在线考试、在线答题也塞进去。我建议第一版先别做。原因很简单题库管理、自动阅卷、防作弊这些功能任何一个都够单独做一个毕设。如果题目里没有明确要求在线考试那作业和问答模块就足够支撑平台的完整度了。我这次做的时候保留了笔记模块实现起来很轻松——笔记模型就是用户、章节、笔记内容、创建时间四个字段页面里在视频播放器下方嵌入一个文本域。这个模块对答辩的价值很大可以解释为“用户学习行为的记录与沉淀”代价却非常小。3. 从业务代码到核心逻辑这些模块页面的完整实现3.1 教师端课程管理连视频上传都没躲过的坑教师端的第一件事是课程创建。表单提交课程基本信息Django的ModelForm在这里能省很多事它会根据模型字段自动生成表单类视图里只要几行代码就能完成校验和保存。视频上传是我特别要提醒的一个坑。如果你直接用FileField写出来的代码确实能跑但视频文件动辄几百兆请求一路传到服务器会非常卡顿而且一旦网络断开就要全部重传。生产实践里至少要处理两个方面。第一个是配一个专门存放媒体文件的路径开发环境下就是设置MEDIA_ROOT和MEDIA_URL。第二个是使用前端切片上传——把大视频切成小块每块单独上传到服务器后端接收时按顺序拼接。Django端对应的代码逻辑是接收分片数据、保存到临时目录、在所有分片到位后合并。在讲这套逻辑时我会跟学生强调一个概念Django的FileField只是管“文件存到哪里、路径存到数据库字段里”真正要在意的是大文件上传的稳定性这属于系统设计的进阶点也是代码讲解时很容易引起评委兴趣的环节。3.2 学生端课程列表与课程详情数据筛选和展示逻辑课程列表页要有两个能力一是按分类筛选二是支持关键词搜索。Django的ORM在这里的用法很标准# 按分类筛选 Course.objects.filter(categoryself.category) # 关键词搜索 Course.objects.filter(title__icontainskeyword)课程详情页要展示课程信息、章节列表、教师信息、报名状态。这里有个典型的Django实践判断当前用户是否已经报名了这门课。实现方式就是查报名表里有没有对应的记录报名表本身是学生和课程的多对多中间表。Django的ManyToManyField可以直接生成这种中间表但更推荐自己额外建一个包含报名时间、学习进度等字段的模型来管理后续做“继续学习”功能会方便得多。比如学生在视频播放页停留了几分钟前端走后端接口把学习进度写进报名记录表课程详情页就能显示“已学40%”。3.3 视频播放页和问答区跨域、鉴权、异步加载的一次集成视频播放页是这个平台最核心的页面也是潜在问题最多的地方。开发环境下用Django自身提供静态文件服务完全没问题部署到服务器后则要交给Nginx来处理媒体文件这样Django进程不用经受大流量的文件传输压力。如果前端使用了视频播放器插件比如vue-video-player或者原生video标签需要注意视频地址的跨域问题。开发阶段通常是同一域名部署后如果文件和页面不在同一域名下就需要在Nginx里配置跨域请求头。问答区可以做成两种形式一种是整页刷新提交答案另一种是异步Ajax提交。我建议用Ajax这样用户体验更好演示的时候也更像一个“平台”。视图返回JSON格式数据即可前端拿到结果往页面上插入一条新的问答记录。有一个细节容易漏掉问答区的用户身份判断。Django自带登录系统能直接在模板里拿到当前请求用户视图里也能直接用request.user。但一定要先判断request.user.is_authenticated否则匿名用户会访问到本不该看到的内容。3.4 管理员后台常用的数据统计与可视化Admin后台自带用户、课程、分类、报名的增删改查但还缺少一个让评委眼前一亮的东西——数据统计。写一个简单的dashboard视图统计注册用户总数、课程总数、报名总人次、最近7天新增用户数然后用Chart.js在页面里画出折线图或柱状图这部分的代码量不大但对整个项目的“完整度”评价影响很大。很多同学担心自己前端不行其实这种后台统计页只需要引用一个Chart.js的文件再把后端传过来的列表数据转成对应的图例格式跟着文档抄一遍就够了。4. 代码讲解不能只讲“能跑”得讲清楚这几个设计细节4.1 用户权限控制的三种常见实现对比答辩的时候老师很爱问“那你怎么保证学生不能访问教师的页面”。这里能讲的方案有三个。方案一是装饰器判断用login_required和user_passes_test这种现成工具把视图函数保护起来实现最快。方案二是自定义中间件从请求进来时统一判断路径前缀和用户角色控制面更集中。方案三是把用户分组放进组里配合Django默认的权限机制来管理。我的建议是代码里先按方案一实现但在文档里把方案二和方案三的原理写进去。这样实在回答又有知识点深度。4.2 Django ORM里的N1查询问题别等到答辩才被发现列表页有时候课程和教师信息是分开的模型里设计是学生在遍历课程时每门课程都要再去查一次教师信息这样返回数据库的次数会很多页面显示自然就慢了。解决办法是用select_related它会把关联表通过一条JOIN查询带出来。在代码讲解时这算一个典型优化点。不需要讲太深的数据库原理只需要展示“优化前调了N1次数据库优化后只调了1次”这样的对比评委就很认可。这个优化在课程列表和章节列表里都能用上。4.3 删除操作必须想清楚物理删除还是逻辑删除Django的模型默认删除是物理删除——数据真的没了。但学习平台里课程删除后用户历史报名记录如果跟着没了就很尴尬。所以生产项目里通常用逻辑删除即给模型增加一个is_deleted或者status字段删除时只是把字段值改掉查询时自动过滤。光是这个细节就能在“平台的设计与实现”的论文里单独写一小节。很多毕设做出来数据表清清爽爽但一被问到“用户注销后他的发言怎么处理”就卡壳逻辑删除就能回答这个问题。代码实现也不难在模型的Manager里重写get_queryset方法查出来的数据自动排除已删除项。4.4 表单验证与安全CSRF和XSS不是摆设在线学习平台的问答区、评论区和作业提交区都是用户输入内容的地方但凡输入之后要展示出来的就必须防XSS。Django模板本身有自动转义只要没有用mark_safe系统的默认防护就能挡住大部分恶意的脚本注入。CSRF又是另一个高频考点。Django的中间件默认开启了CSRF验证前端如果用Ajax提交表单必须把csrftoken带在请求头里。这个问题在开发时最常见——本地明明好好的部署后前端调接口老报403。原因往往就是前端同事不知道Django有这层防护。建议在代码讲解这个环节的时候亲手演示一下“不带CSRF Token的请求怎么被拒绝带上之后怎么通过”这是一段很生动的内容。5. 如何把这份代码变成你答辩时的底气5.1 代码讲解的四段式结构模型、视图、模板、部署代码讲解不是逐行念代码而是要有架构感。我一般建议学生按四段来准备。第一段讲模型用几分钟把用户、课程、章节、作业、报名这几张核心表的关系图在白板上画出来顺手解释一下为什么这样设计。第二段讲视图挑两个代表性的功能比如课程创建和视频上传把从“接收请求”到“返回响应”的完整流程讲清楚。第三段讲模板说明模板继承机制带来的新手友好性怎么用一份base模板统一全站导航和样式。第四段讲部署直接演示服务器上用的启动命令、Nginx静态文件托管和Gunicorn配置这一部分是很多“学完没跑过服务器”的同学最容易露怯的地方提前跑一遍意义很大。5.2 自己预演一遍答辩可能问到的典型问题提前把下面几个问题答案想好答的时候就不慌。“数据库为什么用SQLite不用MySQL”——开发阶段SQLite零配置部署时可以无缝切换到MySQL只要在settings里改一两行配置就行。可以说清楚这一点显得你有数据库环境的概念。“视频是怎么存储的”——开发环境存本地媒体目录生产部署建议上云存储或者挂载磁盘Django代码里通过文件路径访问。“性能有没有考虑”——可以先答平台属于中小型业务量场景Django同步架构完全可以覆盖。再补充一个已经做过的优化比如列表页select_related。“如果有十万用户同时在线你怎么扩展”——这个问题不在毕设考察范围内但也别直接说没想过。你可以说加负载均衡、数据库读写分离、视频文件上CDN这些标准方案一句话带过即可。5.3 一条龙交付里最容易忽略的交档环节拿到别人的源码后最容易忽略的是把交互文档和环境初始化脚本整理清楚。完整的交付内容至少应该包含这几项requirements.txt或环境依赖说明、数据库迁移命令、运行启动命令、初始管理员账号密码。如果要写部署文档建议把步骤写得极其无脑pip install -r requirements.txt python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runserver这几条命令就是这套Django项目从零到跑起来的全部动作。再备一个README写清楚项目结构、核心功能、测试账号。这样不管是自己复习还是给别人看都能节省大量重复沟通时间。6. 常见报错与调试实录6.1 模板继承失效页面样式全丢这类问题90%是根模板的路径写错了。Django加载模板时如果APP里没有注册模板目录或者文件名记错就会静默渲染成空白页。排查方法很简单在浏览器里打开开发者工具看CSS和JS有没有正常加载然后在模板最开头加一个{{ request.path }}确认当前请求到底走到了哪个模板。你会发现大部分时候只是文件名的大小写或者目录层级的问题。6.2 视频上传到一半就断前面提到切片上传是最稳妥的但如果没有时间做那么复杂的前端也有一个替代方案在Nginx配置里调大客户端请求体大小限制client_max_body_size 200m;Django开发服务器不设限但一旦放到真实Nginx环境默认1MB的限制会直接让你的视频上传返回“413 Request Entity Too Large”。这行配置很多初学同学根本不知道存在第一次视频传不上去的时候才去查浪费了很多时间。6.3 部署后刷新404首页正常这是在服务器上跑Django项目最常见的问题。开发模式下Django把URL都处理得好好的但用Gunicorn部署以后静态文件的访问直接404。解决思路很简单开发环境让Django自己提供静态文件生产环境统一交给Nginx处理。配套命令很短但很多人不知道python manage.py collectstatic这个命令会把所有APP里的静态文件复制到一个统一目录下然后Nginx配置里把这个目录映射到一条URL规则搞定。不执行这条命令Django部署后哪怕代码没问题CSS和JS也会损失殆尽页面在浏览器里就是裸的文本加链接。6.4 管理后台密码忘了怎么办如果你在开发过程中经常换数据库玩很可能某天突然就忘了创建过的超级管理员密码。不用慌在项目根目录下执行一条命令就能重新设置python manage.py changepassword 用户名这里稍微扩展一下如果你连用户名都不记得了可以用python manage.py shell进入交互式环境查询一下现有的用户列表。这和每个项目相关的调试技巧比重新建库省力太多。7. 在线学习平台后续还能往哪些方向扩展讲完一套能跑的版本再聊几个进阶方向。这些不一定在毕设阶段全做但在文档的“未来展望”章节里写一下会让整个项目的规划感强很多。方向一引入视频进度追踪。之前报名表里的学习进度字段可以升级为断点续播功能学生在第5分钟关掉视频下次打开自动定位到第5分钟这个功能用前端播放器的currentTime接口就能实现。方向二做一套题库系统。把单选题、多选题、判断题做成数据模型配合在线考试页面的倒计时和自动判分就能把在线学习平台升级成带考试功能的教育系统。方向三积分和证书体系。学生在学完课程后自动获得对应证书或通过积分激励完成每日学习计划这一块能够体现产品思维给评委的第一印象是“这个学生不只是写代码还会想产品”。方向四走微服务或前后端分离改造。如果项目后期代码量变大可以把课程、订单、用户三个模块拆开成独立服务或者引入Django REST Framework做API前端用Vue重构这就可以作为项目进阶的第二篇论文素材了。8. 写在最后别让“拿到源码”变成“只会跑源码”最后一定要叮嘱一句话毕设源码分享、一条龙定制这些东西本质上是给你一个省时间的起点不是终点。源码拿过来以后最重要的任务是把它完全读透然后做两件“改装”的事情第一把项目里的项目名、数据库名、标题这些改成自己的第二往里面加一个原创的小功能比如一个学习日历、一个课程收藏夹哪怕只有一百行代码答辩时的底气和交源码前的心情都会完全不同。这既是对学习成果的交代也是对自己负责。这套Django在线学习平台的代码本身不难难的是你愿不愿意把它从“能跑的项目”变成“讲得清的成果”。跑通了然后敢站起来讲这个毕设就稳了。