企业官网建设流程全解析

毕设做到一半，你会发现最难的不是写代码，而是搞清楚“这门课到底要我做出来个什么东西”。尤其是“在线学习平台”这种题目，听起来谁都能做、满大街都是，但真要交出去，又要能跑、又要有文档、又要答得上答辩老师随口一句“这个权限是怎么控制的”，就麻烦得很了。

这篇文章我就以一套实际交付过的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(category=self.category) # 关键词搜索 Course.objects.filter(title__icontains=keyword)

课程详情页要展示课程信息、章节列表、教师信息、报名状态。这里有个典型的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里的N+1查询问题，别等到答辩才被发现

列表页有时候课程和教师信息是分开的，模型里设计是学生在遍历课程时，每门课程都要再去查一次教师信息，这样返回数据库的次数会很多，页面显示自然就慢了。解决办法是用select_related，它会把关联表通过一条JOIN查询带出来。

在代码讲解时，这算一个典型优化点。不需要讲太深的数据库原理，只需要展示“优化前调了N+1次数据库，优化后只调了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在线学习平台的代码本身不难，难的是你愿不愿意把它从“能跑的项目”变成“讲得清的成果”。跑通了，然后敢站起来讲，这个毕设就稳了。