线上授课系统这个题目我每年在帮人看开题、读源码的时候都能碰上十几次。它几乎成了计算机相关专业毕设选题里的“常青树”——需求好理解、功能看着熟、网上现成的代码一大堆看上去是个稳赚不赔的选择。但真动手做过一轮的人都知道这个题目最容易出现的情况是功能列表写了两页纸代码跑起来只有登录和增删改查答辩时被问一句“你的课堂互动怎么保证实时性”就直接卡壳。这篇内容我想从头到尾把这个项目拆一遍包括整体架构怎么定、数据表怎么设计、核心模块怎么落地、开题报告怎么写才不被退、拿到一套源码之后按什么顺序接手改造以及那些只有真正跑过一遍才会知道的问题。刚入门、准备做课设或毕设的读者可以把它当成一份施工顺序表已经写过一版、但觉得项目“很空”的读者可以重点看数据模型和实时互动那几节那通常是拉开差距的地方。1. 先搞清楚这个选题到底在做什么1.1 线上授课系统的四类角色与真实业务闭环很多人一上来就写功能列表写着写着就散了原因是没有先把“谁在用、按什么顺序用”这件事想明白。线上授课系统的业务闭环本质上是四种角色围绕“一门课”的完整生命周期展开的。管理员负责用户与课程的顶层管理审核开课申请、维护院系与班级结构、查看全平台数据、处理异常账号。教师创建课程、编排章节目录、上传课件与录播、发起直播或签到、布置作业与考试、批阅与统计成绩。学生选课、看课件、看录播、进入课堂、交作业、参加考试、查成绩与学习进度。助教可选但很加分协助批阅、答疑、导出名单。把这四条线画清楚之后你会发现真正的难点不在“能不能存数据”而在状态流转一门课从“草稿”到“已发布”到“进行中”到“已结课”一个作业从“未提交”到“已提交”到“已批阅”到“可申诉”一次考试从“未开始”到“进行中”到“已交卷”到“已阅卷”。这些状态如果只是用一个字段随便存个 0/1后期一定会乱。我的建议是把状态定义成枚举并且在数据库里加注释说明每个值的含义代码里统一走一个状态机判断而不是散落在各个 Service 里写 if。注意不要试图在第一个版本里把四种角色全部做满。合理做法是先做通“教师发布—学生查看”这条主链路把状态流转跑顺再去补管理端和助教端。主链路不通功能再多也是散的。1.2 为什么这个题目年年有人做却年年做不好我观察下来做不好的原因基本集中在三个地方。第一是把它做成了内容管理系统只会上传文件、列表展示、分页查询一旦被问到“课中怎么办”就答不上来。第二是没有真实的并发与时间约束比如签到、抢答、限时考试这些功能的价值恰恰体现在“同一时刻很多人同时操作”不处理这个功能就是玩具。第三是数据表设计欠债学生选课表和学生成绩表混在一起课程表和章节表主外键关系含糊等到要做统计报表时只能写一堆子查询硬凑。所以我在动手前会先问自己三个问题这门课的核心数据实体有几个哪些操作是“时间敏感的”哪些数据是“只增不改”的这三个问题的答案直接决定了架构复杂度和表结构。时间敏感的操作适合走缓存和消息通道只增不改的数据日志、答题记录适合单独拆表并做好索引剩下的常规业务走标准的三层结构就够了。2. 技术选型与整体架构怎么定2.1 后端框架与数据库的取舍逻辑技术选型这件事我的原则是“选生态最厚的不选最潮的”。因为你要在有限时间里解决大量业务细节遇到问题时能搜到答案比框架本身优雅重要得多。下面是我这几年反复用过、也比较稳妥的一套组合以及每一项的选择理由。层次常见选择选它的理由什么情况下换掉后端框架Spring Boot生态完整鉴权、缓存、定时任务都有成熟整合方案团队更熟 Python 可选 Flask/FastAPI但要自己补鉴权体系数据库MySQL关系清晰事务支持好选课、成绩这类强一致场景够用需要存大量非结构化课件内容时可加 MongoDB缓存Redis验证码、登录态、签到名单、排行榜都靠它单机学习项目可以先用内存缓存替代实时通道WebSocket课堂消息、在线状态、抢答需要双向推送只做单向通知可用 SSE实现更轻前端Vue 或 React组件化适合多角色界面路由权限好做不想折腾构建工具就用模板引擎直出文件存储本地目录起步省事调试直观课件体积大时换对象存储并做分片上传有一点必须说清楚视频直播这件事不要在毕设阶段试图自己实现推拉流。完整的流媒体链路涉及编码、转码、切片、分发工作量远超一个课程项目该有的范围。合理的做法是两种要么用“录播 时间轴同步”模拟上课教师预置课件页和讲解音频前端按时间轴翻页要么直接用第三方提供的嵌入式播放能力只做鉴权和进度上报。答辩时把“为什么不做自研推流”讲清楚反而是加分项因为它证明你懂得界定项目边界。2.2 分层结构与目录规划分层这件事很多项目名义上分了 Controller、Service、Mapper实际上业务逻辑全塞在 Controller 里Service 只是一层转发。我的习惯是按下面的方式落地每一层职责写死在团队约定里src/main/java/com/example/teach ├── controller 只做参数校验与响应封装不写业务 ├── service 业务编排事务边界在这一层 ├── service/impl 具体实现复杂逻辑拆成私有方法 ├── mapper 数据访问SQL 集中管理 ├── entity 与表一一对应的实体 ├── dto 出入参对象与 entity 严格区分 ├── config 拦截器、跨域、WebSocket、缓存配置 ├── common 统一返回体、全局异常、枚举、常量 └── util 工具类不含业务把 DTO 和 Entity 分开这件事看起来是多余的工作量实际上收益很大。学生列表接口返回的字段和数据库表的字段往往不一致比如密码哈希绝对不能出现在响应里课程列表要带上教师姓名和选课人数这些都需要专门的出参对象。一旦混用实体某个接口不小心多返回了敏感字段排查起来非常痛苦。2.3 前端技术栈的选型权衡前端这块我倾向于“能用组件库就不手写”。线上授课系统的界面数量多但结构重复度高无非是列表页、详情页、表单页、统计页的组合。用现成的组件库把表格、分页、弹窗、上传做出来能省掉大量时间把精力放到状态管理和权限控制上。真正需要自己设计的是两件事。一是路由级的权限控制不同角色登录后应该看到完全不同的侧边栏这个不要靠页面上 v-if 判断按钮显隐来实现那样既难维护也不安全正确做法是登录后由后端返回该角色的菜单树前端据此动态注册路由。二是全局的请求拦截统一处理 token 过期、后端返回的业务错误码、加载状态避免每个页面都写一遍 try-catch。3. 数据库设计整个项目最容易翻车的地方3.1 核心表结构与字段设计我把这个系统的表分成四组账号与组织、课程与内容、互动与作业、日志与统计。下面挑最关键的几张表说清楚字段的设计意图。表名关键字段设计意图说明userid, account, pwd_hash, real_name, role, statusrole 用枚举区分四类角色status 控制禁用courseid, title, teacher_id, cover, intro, status, start_at, end_atstatus 表示草稿/已发布/进行中/已结课course_chapterid, course_id, parent_id, title, sort_no, typeparent_id 自关联做两级目录type 区分章与节chapter_resourceid, chapter_id, res_type, url, duration, sizeres_type 区分视频/文档/链接duration 用于进度计算course_enrollid, course_id, student_id, enroll_at, status唯一索引 (course_id, student_id) 防重复选课homeworkid, course_id, title, deadline, full_score, allow_lateallow_late 决定逾期是否可提交homework_submitid, homework_id, student_id, content, file_url, submit_at, score, comment一人一份唯一索引约束examid, course_id, title, start_at, end_at, duration, shuffleduration 为限时分钟数shuffle 控制题序随机exam_questionid, exam_id, q_type, stem, options, answer, score, sort_nooptions 用 JSON 存选项answer 存标准答案exam_recordid, exam_id, student_id, start_at, submit_at, score, statusstatus 表示未开始/进行中/已交卷/已阅卷study_progressid, student_id, resource_id, progress, updated_at记录每个资源的观看进度百分比sign_inid, course_id, teacher_id, start_at, expire_at, codecode 为短时有效的签到码这里有几个字段值得单独说。study_progress 的 progress 用整数存百分比而不是布尔值因为学生可能看到一半退出下次要能续播如果只存“看过/没看过”体验会差很多而这个改动成本极低。exam_record 的 start_at 很重要它决定了这个学生这次考试的截止时间晚于“考试结束时间”和“个人开始时间 时长”中较早的那个就不能再提交这个逻辑必须在后端做前端倒计时只是提示。3.2 几个必须提前想清楚的设计细节第一个细节是软删除。课程、章节这类数据一旦被引用学生有选课记录、有作业提交物理删除会造成大量孤儿数据。我的做法是加一个 deleted 标记位查询时统一过滤同时给常用查询字段建联合索引。代价是每个查询都要记得带条件所以我通常会在 Mapper 层写一个基础查询片段避免遗漏。第二个细节是选课人数的统计。新手常见写法是每次查课程列表都 count 一次选课表课程多了之后这是典型的 N1 问题。简单有效的解决方式是给 course 表加一个冗余字段 enroll_count选课和退课时同步更新同时用一个定时任务在低峰期做一次全量校正。这个“冗余字段 定期校正”的思路在点赞数、评论数这类场景里都通用。第三个细节是时间字段统一用 DATETIME 而不是字符串并且全部由后端生成不收前端的值。我见过有项目让前端传提交时间结果学生改一下系统时间就能绕过截止限制。截止判断一定要用服务端时间并且做一次时钟校验。提示建表的时候就把索引一起规划好。像 course_enroll(course_id, student_id)、homework_submit(homework_id, student_id)、study_progress(student_id, resource_id) 这几组唯一索引能同时解决唯一性约束和查询加速两个问题。4. 核心功能模块的实现要点4.1 登录鉴权与角色权限控制登录这块现在还在用“用户名 明文密码”的项目我见一次劝一次。哪怕只是课设也应该做到密码加盐哈希存储用 BCrypt 这类成熟实现几行代码的事。登录成功后签发 tokentoken 里带上用户 id 和角色服务端用拦截器统一校验把用户信息放进线程上下文业务层直接取避免每个接口都手动解析。权限控制要分两层。接口级判断“这个角色能不能调用这个接口”比如只有教师能创建课程这个在拦截器里根据注解或路径前缀判断数据级判断“这个用户能不能操作这条数据”比如教师 A 不能修改教师 B 的课程这个必须在 Service 层查一次归属再决定不能只靠前端隐藏按钮。我见过不少项目栽在这里答辩时老师随手改一个 id 就能越权看到别人的成绩这比功能少扣分严重得多。// 数据级权限校验的典型写法先查归属再判断再执行 Course course courseMapper.selectById(courseId); if (course null) { throw new BizException(课程不存在); } if (!course.getTeacherId().equals(currentUserId())) { throw new BizException(无权操作该课程); }4.2 课程与章节内容管理课程内容的组织方式直接决定了后续所有功能的复杂度。我的建议是“课程—章—节—资源”四级结构章和节用同一张表通过 parent_id 自关联资源单独一张表挂在节下面。这样做的原因是一门课的目录往往需要拖动排序、增删调整如果章和节分成两张表每次调整都要跨表操作非常别扭。资源上传是另一个需要认真对待的点。课件常见的是 PDF、PPT、视频三类体积差异巨大。基础版可以直接存本地磁盘路径写进数据库但要处理好三件事文件名要重命名用 UUID 加后缀原始文件名单独存一列用于展示防止中文名和特殊字符引发问题、大小要做限制在配置里设置单文件和总大小上限避免被传爆磁盘、类型要白名单校验不能只看后缀还要看 Content-Type。视频文件建议单独做一次分片上传哪怕是简化版也能让答辩时“大文件怎么办”这个问题有答案。4.3 在线课堂与实时互动这是最能体现项目含金量的模块也是大部分人做得最薄的地方。我把它拆成四个可独立实现的小功能按难度递增在线状态与签到。教师发起签到时生成一个六位随机码写进 Redis 并设置过期时间比如 60 秒学生凭码签到。Redis 的 Set 结构天然适合存“已签到名单”用 SADD 保证同一学生只记一次用 SCARD 拿实时人数。这个方案的好处是完全不落库就能撑住课中的高频写入课后再异步把结果批量写回数据库。课堂消息通道。用 WebSocket 建一条长连接按课程 id 分组教师发的消息广播给该组所有学生。这里要注意连接管理和心跳客户端定时发心跳服务端超过一定时间没收到就主动断开并清理会话否则会积累大量僵尸连接。// 前端建立连接并处理心跳的最小实现 const ws new WebSocket(/ws/class/${courseId}?token${token}); let timer null; ws.onopen () { timer setInterval(() ws.send(JSON.stringify({ type: ping })), 25000); }; ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type pong) return; handleMessage(msg); }; ws.onclose () clearInterval(timer);随堂提问与抢答。教师抛出一个问题学生点击抢答服务端按到达顺序取第一个广播结果。这里的关键是并发下的顺序问题单机可以用队列串行处理多实例部署时要用 Redis 的原子操作抢锁。课堂资源同步翻页。教师端切到第几页课件学生端跟着切。实现上就是把当前页码作为一条消息广播出去学生端收到后滚动到对应位置。功能不复杂但演示效果极好因为它直观地体现了“线上课堂不是看录像”。4.4 作业、考试与自动判分作业模块的核心是截止时间与状态判断。提交时服务端比对当前时间和 deadline允许迟交的才放行并且标记为迟交。批阅时教师写分数和评语学生端要能看到批阅状态的变化这里用轮询或者简单的消息通知都可以不必上复杂方案。考试模块要复杂一些因为它有“限时”这个强约束。我的做法是学生点击开始考试时创建一条 exam_record 并记录 start_at同时把试卷题目按顺序或随机打乱后落一份快照到该记录下。之所以要快照是因为如果考试期间教师修改了题目已经开考的学生不应该受影响。截止时间取“考试统一结束时间”和“个人开始时间 时长”的较小值交卷时后端再校验一次。自动判分只对客观题有效单选题比对答案多选题要比对集合是否完全一致漏选和错选要区分对待这个规则要在开题时写清楚。主观题保留人工批阅入口。这里我建议加一个“答题过程自动保存”的小功能学生每答一题就异步上报一次防止浏览器崩溃导致答案丢失这个细节在演示时非常能打动人。4.5 学习行为统计统计模块是我认为最容易被忽略、但对项目完整度提升最大的部分。有了它系统才不是单纯的“资料仓库”。可以做的统计有课程维度的资源完成率、作业提交率、平均分分布学生维度的累计学习时长、各科进度对比教师维度的班级活跃度。实现上基础版用几条聚合 SQL 就够了复杂一点的可以加一张按天汇总的统计表由定时任务在凌晨跑批生成避免每次打开报表都扫全表。5. 开题报告怎么写才不被退回5.1 开题报告的固定骨架与每部分的写作要点开题被退回多数不是内容不够而是逻辑链断了前面的需求分析和后面的技术方案对不上功能列表和进度安排对不上。我通常按下面这个顺序组织每一部分都回答一个明确的问题。部分要回答的问题常见扣分点选题背景与意义为什么这个场景值得做空话套话没有具体场景描述国内外研究现状别人做到什么程度了罗列产品名没有归纳出功能维度研究内容与目标你要做出什么功能列表堆砌没有主次技术路线用什么做、为什么用它只写框架名不写选型理由关键问题与难点你打算攻哪几个点难点写成“时间紧张”这类非技术问题进度安排每个阶段产出什么阶段划分过粗最后两周写测试参考文献依据是什么格式混乱数量不足写“研究内容”时我建议用“主链路 增强点”的结构先描述一条完整的主链路教师开课 → 上传内容 → 学生选课学习 → 作业考试 → 成绩统计再点出两到三个增强点实时互动、自动判分、学习行为分析。这样评审一眼就能看出你的项目有骨架也有亮点而不是一堆并列的功能名词。5.2 创新点与工作量怎么包装才算合理关于“创新点”我一直觉得这个词被用坏了。一个课程项目谈颠覆式创新不现实但谈场景化的改进完全站得住脚。比较稳的写法有三种一是针对某个具体痛点做优化比如“针对线上课堂学生注意力难保证的问题设计了随堂抢答与签到联动机制”二是做技术上的组合应用比如“将缓存与消息通道结合支撑课中高频互动”三是做体验层面的改进比如“资源进度断点续播与答题过程自动保存”。包的时候注意一个原则创新点必须能在演示中被看到。写在纸上但演示不出来的东西答辩时反而会成为追问点。至于工作量不要靠堆功能数量而是靠“每个模块都有可展示的完整闭环”。五个做通的功能远胜十五个只有列表页的功能。注意进度安排里一定要给“联调与测试”留出至少两周。我见过太多项目计划把最后一周写成“完善功能”结果联调阶段数据库字段改了三遍最后演示的是个半成品。6. 源码怎么读、怎么改成自己的6.1 拿到一套源码后的接手顺序网上现成的项目源码直接跑起来容易真正理解要按顺序来。我的接手顺序是先看依赖和配置再看表结构再看路由最后看核心业务。配置里能看出用了哪些中间件、连了什么库、端口怎么分配表结构能看出作者对业务的理解程度也能预判哪里会出问题路由列表能快速建立功能地图最后才是逐模块读业务代码。跑起来的过程中最常见的三个坎是数据库脚本执行报错多半是版本差异导致语法不兼容、依赖下载失败换镜像源或用离线包、配置项没改数据库账号、文件路径、端口冲突。这三个问题解决了八成以上能跑通。6.2 二次改造的常见方向跑通之后别急着大改先做一次“体检”。我会重点看四处有没有做权限校验很多源码只做了登录没做数据级校验、密码是不是明文如果是第一时间改掉、有没有硬编码的配置账号密码写死在代码里、删除操作是物理还是逻辑。这四处是改造性价比最高的地方。改造方向上我建议优先补“实时互动”和“统计报表”因为这两块最能体现个人工作量且不容易和别人撞车。如果时间充裕可以加一个“课程评价与反馈”模块教师能看到学生对每节课的评分和留言这个功能实现简单但业务价值清晰写进论文里也容易展开。7. 部署、联调与演示答辩的实操细节7.1 本地环境跑起来的最小路径为了少踩坑我习惯按下面的顺序推进每一步确认通了再走下一步先建库、执行建表脚本用客户端连上去确认表和索引都在。后端只启动一个空壳工程确认端口能访问、健康检查接口返回正常。接入数据库跑通一个最简单的查询接口。接入前端确认跨域配置正确、请求能打通。补上登录与拦截器确认未登录请求被正确拦截。逐个模块补业务接口每补完一个就用接口工具验证一次。最后接 WebSocket 和文件上传这两块最容易出环境问题放后面。# 打包与启动的常用命令注意把配置外置别写死在包里 mvn clean package -DskipTests java -jar target/teach-system.jar --spring.profiles.activedev7.2 答辩演示的稳定性保障演示翻车是这个项目最大的风险而且往往翻在莫名其妙的地方。我的经验是准备三份数据一份干净的初始数据用于展示新建流程、一份已经填充好的完整数据用于展示列表和统计避免现场造数据、一份降级方案录屏或截图网络或环境出问题时能顶上。演示顺序也要设计先展示最稳的登录和课程列表再展示中间态的作业提交与批阅最后展示实时互动这个亮点。不要一上来就演示最复杂的功能万一卡住后面心态会崩。另外提前把浏览器缓存清掉、把无关标签页关掉、把通知关掉这些小事在答辩现场格外重要。8. 常见问题速查与避坑清单8.1 开发阶段高频问题现象大概率原因处理方式前端请求报跨域错误后端未配置允许来源或预检请求被拦截统一在配置类里放开来源与请求方法注意携带凭证时要指定具体来源登录后立刻掉线token 未正确携带或拦截器未放行静态资源检查请求头与拦截器排除路径上传大文件失败框架与容器的大小限制未调整同时调整框架配置和容器配置两处缺一不可列表接口越翻越慢深分页扫表或缺联合索引加索引改用基于游标的分页WebSocket 连不上路径被拦截器拦下或反向代理未放行升级请求拦截器排除该路径代理配置支持协议升级考试倒计时归零还能提交只在前端做了判断后端在交卷接口重新校验时间统计数据对不上冗余计数字段与真实数据漂移加定时校正任务并记录校正日志8.2 一些踩过才知道的坑关于时间。前后端时间不一致是最隐蔽的 bug。服务端统一用 UTC 或统一时区存储返回给前端时格式化成带时区的标准字符串前端展示时再转本地时间。我吃过一次亏服务器时区是 UTC前端按本地时间显示考试开始时间整整差了八小时测试时怎么都对不上。关于并发。选课人数、抢答顺序、签到名单这三处是最典型的并发点。能用数据库唯一索引挡住的就别用代码判断能用 Redis 原子操作解决的就别用先查再写。考试名额、签到人数这类场景加一次数据库层面的唯一约束比写十个 if 都管用。关于测试数据。一定要在项目中期就开始造数据不要等到最后一天。一门课至少造三十个学生、十次作业、两次考试数据量起来了才能发现分页、统计、排序的问题。只有三条测试数据的系统看起来永远是对的。关于代码整洁度。答辩老师不一定细看代码但一定会翻。实体类命名混乱、注释全是英文模板、控制台一堆调试输出这些细节会直接影响印象分。花两个小时把命名统一、把无用的引入删掉、把配置里的测试账号清掉收益比再加一个功能高得多。关于演示用的账号。至少准备四个账号管理员、教师、学生、助教各一个密码统一但不要把密码写在幻灯片上。演示前逐个登录一次确认每个角色的菜单和权限都正常这一步能挡掉大部分现场事故。我在实际做这个项目的过程中感受最深的一点是线上的课堂永远无法完全替代线下的即时感所以系统的价值不在于把线下的流程原样搬上来而在于用技术手段补上线下做不到的部分——比如学生可以反复回看某一段讲解教师能看到每个学生的进度差异并针对性提醒作业批改结果能沉淀成可检索的历史记录。想清楚这一点功能取舍就有了依据也就不会陷进“别人有的我也要有”的功能比拼里。 
长河君 · 2026/10/27 13:12:37 · 阅读 1.2k 线上授课系统毕设落地指南：架构、数据库与实时互动
线上授课系统这个题目我每年在帮人看开题、读源码的时候都能碰上十几次。它几乎成了计算机相关专业毕设选题里的“常青树”——需求好理解、功能看着熟、网上现成的代码一大堆看上去是个稳赚不赔的选择。但真动手做过一轮的人都知道这个题目最容易出现的情况是功能列表写了两页纸代码跑起来只有登录和增删改查答辩时被问一句“你的课堂互动怎么保证实时性”就直接卡壳。这篇内容我想从头到尾把这个项目拆一遍包括整体架构怎么定、数据表怎么设计、核心模块怎么落地、开题报告怎么写才不被退、拿到一套源码之后按什么顺序接手改造以及那些只有真正跑过一遍才会知道的问题。刚入门、准备做课设或毕设的读者可以把它当成一份施工顺序表已经写过一版、但觉得项目“很空”的读者可以重点看数据模型和实时互动那几节那通常是拉开差距的地方。1. 先搞清楚这个选题到底在做什么1.1 线上授课系统的四类角色与真实业务闭环很多人一上来就写功能列表写着写着就散了原因是没有先把“谁在用、按什么顺序用”这件事想明白。线上授课系统的业务闭环本质上是四种角色围绕“一门课”的完整生命周期展开的。管理员负责用户与课程的顶层管理审核开课申请、维护院系与班级结构、查看全平台数据、处理异常账号。教师创建课程、编排章节目录、上传课件与录播、发起直播或签到、布置作业与考试、批阅与统计成绩。学生选课、看课件、看录播、进入课堂、交作业、参加考试、查成绩与学习进度。助教可选但很加分协助批阅、答疑、导出名单。把这四条线画清楚之后你会发现真正的难点不在“能不能存数据”而在状态流转一门课从“草稿”到“已发布”到“进行中”到“已结课”一个作业从“未提交”到“已提交”到“已批阅”到“可申诉”一次考试从“未开始”到“进行中”到“已交卷”到“已阅卷”。这些状态如果只是用一个字段随便存个 0/1后期一定会乱。我的建议是把状态定义成枚举并且在数据库里加注释说明每个值的含义代码里统一走一个状态机判断而不是散落在各个 Service 里写 if。注意不要试图在第一个版本里把四种角色全部做满。合理做法是先做通“教师发布—学生查看”这条主链路把状态流转跑顺再去补管理端和助教端。主链路不通功能再多也是散的。1.2 为什么这个题目年年有人做却年年做不好我观察下来做不好的原因基本集中在三个地方。第一是把它做成了内容管理系统只会上传文件、列表展示、分页查询一旦被问到“课中怎么办”就答不上来。第二是没有真实的并发与时间约束比如签到、抢答、限时考试这些功能的价值恰恰体现在“同一时刻很多人同时操作”不处理这个功能就是玩具。第三是数据表设计欠债学生选课表和学生成绩表混在一起课程表和章节表主外键关系含糊等到要做统计报表时只能写一堆子查询硬凑。所以我在动手前会先问自己三个问题这门课的核心数据实体有几个哪些操作是“时间敏感的”哪些数据是“只增不改”的这三个问题的答案直接决定了架构复杂度和表结构。时间敏感的操作适合走缓存和消息通道只增不改的数据日志、答题记录适合单独拆表并做好索引剩下的常规业务走标准的三层结构就够了。2. 技术选型与整体架构怎么定2.1 后端框架与数据库的取舍逻辑技术选型这件事我的原则是“选生态最厚的不选最潮的”。因为你要在有限时间里解决大量业务细节遇到问题时能搜到答案比框架本身优雅重要得多。下面是我这几年反复用过、也比较稳妥的一套组合以及每一项的选择理由。层次常见选择选它的理由什么情况下换掉后端框架Spring Boot生态完整鉴权、缓存、定时任务都有成熟整合方案团队更熟 Python 可选 Flask/FastAPI但要自己补鉴权体系数据库MySQL关系清晰事务支持好选课、成绩这类强一致场景够用需要存大量非结构化课件内容时可加 MongoDB缓存Redis验证码、登录态、签到名单、排行榜都靠它单机学习项目可以先用内存缓存替代实时通道WebSocket课堂消息、在线状态、抢答需要双向推送只做单向通知可用 SSE实现更轻前端Vue 或 React组件化适合多角色界面路由权限好做不想折腾构建工具就用模板引擎直出文件存储本地目录起步省事调试直观课件体积大时换对象存储并做分片上传有一点必须说清楚视频直播这件事不要在毕设阶段试图自己实现推拉流。完整的流媒体链路涉及编码、转码、切片、分发工作量远超一个课程项目该有的范围。合理的做法是两种要么用“录播 时间轴同步”模拟上课教师预置课件页和讲解音频前端按时间轴翻页要么直接用第三方提供的嵌入式播放能力只做鉴权和进度上报。答辩时把“为什么不做自研推流”讲清楚反而是加分项因为它证明你懂得界定项目边界。2.2 分层结构与目录规划分层这件事很多项目名义上分了 Controller、Service、Mapper实际上业务逻辑全塞在 Controller 里Service 只是一层转发。我的习惯是按下面的方式落地每一层职责写死在团队约定里src/main/java/com/example/teach ├── controller 只做参数校验与响应封装不写业务 ├── service 业务编排事务边界在这一层 ├── service/impl 具体实现复杂逻辑拆成私有方法 ├── mapper 数据访问SQL 集中管理 ├── entity 与表一一对应的实体 ├── dto 出入参对象与 entity 严格区分 ├── config 拦截器、跨域、WebSocket、缓存配置 ├── common 统一返回体、全局异常、枚举、常量 └── util 工具类不含业务把 DTO 和 Entity 分开这件事看起来是多余的工作量实际上收益很大。学生列表接口返回的字段和数据库表的字段往往不一致比如密码哈希绝对不能出现在响应里课程列表要带上教师姓名和选课人数这些都需要专门的出参对象。一旦混用实体某个接口不小心多返回了敏感字段排查起来非常痛苦。2.3 前端技术栈的选型权衡前端这块我倾向于“能用组件库就不手写”。线上授课系统的界面数量多但结构重复度高无非是列表页、详情页、表单页、统计页的组合。用现成的组件库把表格、分页、弹窗、上传做出来能省掉大量时间把精力放到状态管理和权限控制上。真正需要自己设计的是两件事。一是路由级的权限控制不同角色登录后应该看到完全不同的侧边栏这个不要靠页面上 v-if 判断按钮显隐来实现那样既难维护也不安全正确做法是登录后由后端返回该角色的菜单树前端据此动态注册路由。二是全局的请求拦截统一处理 token 过期、后端返回的业务错误码、加载状态避免每个页面都写一遍 try-catch。3. 数据库设计整个项目最容易翻车的地方3.1 核心表结构与字段设计我把这个系统的表分成四组账号与组织、课程与内容、互动与作业、日志与统计。下面挑最关键的几张表说清楚字段的设计意图。表名关键字段设计意图说明userid, account, pwd_hash, real_name, role, statusrole 用枚举区分四类角色status 控制禁用courseid, title, teacher_id, cover, intro, status, start_at, end_atstatus 表示草稿/已发布/进行中/已结课course_chapterid, course_id, parent_id, title, sort_no, typeparent_id 自关联做两级目录type 区分章与节chapter_resourceid, chapter_id, res_type, url, duration, sizeres_type 区分视频/文档/链接duration 用于进度计算course_enrollid, course_id, student_id, enroll_at, status唯一索引 (course_id, student_id) 防重复选课homeworkid, course_id, title, deadline, full_score, allow_lateallow_late 决定逾期是否可提交homework_submitid, homework_id, student_id, content, file_url, submit_at, score, comment一人一份唯一索引约束examid, course_id, title, start_at, end_at, duration, shuffleduration 为限时分钟数shuffle 控制题序随机exam_questionid, exam_id, q_type, stem, options, answer, score, sort_nooptions 用 JSON 存选项answer 存标准答案exam_recordid, exam_id, student_id, start_at, submit_at, score, statusstatus 表示未开始/进行中/已交卷/已阅卷study_progressid, student_id, resource_id, progress, updated_at记录每个资源的观看进度百分比sign_inid, course_id, teacher_id, start_at, expire_at, codecode 为短时有效的签到码这里有几个字段值得单独说。study_progress 的 progress 用整数存百分比而不是布尔值因为学生可能看到一半退出下次要能续播如果只存“看过/没看过”体验会差很多而这个改动成本极低。exam_record 的 start_at 很重要它决定了这个学生这次考试的截止时间晚于“考试结束时间”和“个人开始时间 时长”中较早的那个就不能再提交这个逻辑必须在后端做前端倒计时只是提示。3.2 几个必须提前想清楚的设计细节第一个细节是软删除。课程、章节这类数据一旦被引用学生有选课记录、有作业提交物理删除会造成大量孤儿数据。我的做法是加一个 deleted 标记位查询时统一过滤同时给常用查询字段建联合索引。代价是每个查询都要记得带条件所以我通常会在 Mapper 层写一个基础查询片段避免遗漏。第二个细节是选课人数的统计。新手常见写法是每次查课程列表都 count 一次选课表课程多了之后这是典型的 N1 问题。简单有效的解决方式是给 course 表加一个冗余字段 enroll_count选课和退课时同步更新同时用一个定时任务在低峰期做一次全量校正。这个“冗余字段 定期校正”的思路在点赞数、评论数这类场景里都通用。第三个细节是时间字段统一用 DATETIME 而不是字符串并且全部由后端生成不收前端的值。我见过有项目让前端传提交时间结果学生改一下系统时间就能绕过截止限制。截止判断一定要用服务端时间并且做一次时钟校验。提示建表的时候就把索引一起规划好。像 course_enroll(course_id, student_id)、homework_submit(homework_id, student_id)、study_progress(student_id, resource_id) 这几组唯一索引能同时解决唯一性约束和查询加速两个问题。4. 核心功能模块的实现要点4.1 登录鉴权与角色权限控制登录这块现在还在用“用户名 明文密码”的项目我见一次劝一次。哪怕只是课设也应该做到密码加盐哈希存储用 BCrypt 这类成熟实现几行代码的事。登录成功后签发 tokentoken 里带上用户 id 和角色服务端用拦截器统一校验把用户信息放进线程上下文业务层直接取避免每个接口都手动解析。权限控制要分两层。接口级判断“这个角色能不能调用这个接口”比如只有教师能创建课程这个在拦截器里根据注解或路径前缀判断数据级判断“这个用户能不能操作这条数据”比如教师 A 不能修改教师 B 的课程这个必须在 Service 层查一次归属再决定不能只靠前端隐藏按钮。我见过不少项目栽在这里答辩时老师随手改一个 id 就能越权看到别人的成绩这比功能少扣分严重得多。// 数据级权限校验的典型写法先查归属再判断再执行 Course course courseMapper.selectById(courseId); if (course null) { throw new BizException(课程不存在); } if (!course.getTeacherId().equals(currentUserId())) { throw new BizException(无权操作该课程); }4.2 课程与章节内容管理课程内容的组织方式直接决定了后续所有功能的复杂度。我的建议是“课程—章—节—资源”四级结构章和节用同一张表通过 parent_id 自关联资源单独一张表挂在节下面。这样做的原因是一门课的目录往往需要拖动排序、增删调整如果章和节分成两张表每次调整都要跨表操作非常别扭。资源上传是另一个需要认真对待的点。课件常见的是 PDF、PPT、视频三类体积差异巨大。基础版可以直接存本地磁盘路径写进数据库但要处理好三件事文件名要重命名用 UUID 加后缀原始文件名单独存一列用于展示防止中文名和特殊字符引发问题、大小要做限制在配置里设置单文件和总大小上限避免被传爆磁盘、类型要白名单校验不能只看后缀还要看 Content-Type。视频文件建议单独做一次分片上传哪怕是简化版也能让答辩时“大文件怎么办”这个问题有答案。4.3 在线课堂与实时互动这是最能体现项目含金量的模块也是大部分人做得最薄的地方。我把它拆成四个可独立实现的小功能按难度递增在线状态与签到。教师发起签到时生成一个六位随机码写进 Redis 并设置过期时间比如 60 秒学生凭码签到。Redis 的 Set 结构天然适合存“已签到名单”用 SADD 保证同一学生只记一次用 SCARD 拿实时人数。这个方案的好处是完全不落库就能撑住课中的高频写入课后再异步把结果批量写回数据库。课堂消息通道。用 WebSocket 建一条长连接按课程 id 分组教师发的消息广播给该组所有学生。这里要注意连接管理和心跳客户端定时发心跳服务端超过一定时间没收到就主动断开并清理会话否则会积累大量僵尸连接。// 前端建立连接并处理心跳的最小实现 const ws new WebSocket(/ws/class/${courseId}?token${token}); let timer null; ws.onopen () { timer setInterval(() ws.send(JSON.stringify({ type: ping })), 25000); }; ws.onmessage (e) { const msg JSON.parse(e.data); if (msg.type pong) return; handleMessage(msg); }; ws.onclose () clearInterval(timer);随堂提问与抢答。教师抛出一个问题学生点击抢答服务端按到达顺序取第一个广播结果。这里的关键是并发下的顺序问题单机可以用队列串行处理多实例部署时要用 Redis 的原子操作抢锁。课堂资源同步翻页。教师端切到第几页课件学生端跟着切。实现上就是把当前页码作为一条消息广播出去学生端收到后滚动到对应位置。功能不复杂但演示效果极好因为它直观地体现了“线上课堂不是看录像”。4.4 作业、考试与自动判分作业模块的核心是截止时间与状态判断。提交时服务端比对当前时间和 deadline允许迟交的才放行并且标记为迟交。批阅时教师写分数和评语学生端要能看到批阅状态的变化这里用轮询或者简单的消息通知都可以不必上复杂方案。考试模块要复杂一些因为它有“限时”这个强约束。我的做法是学生点击开始考试时创建一条 exam_record 并记录 start_at同时把试卷题目按顺序或随机打乱后落一份快照到该记录下。之所以要快照是因为如果考试期间教师修改了题目已经开考的学生不应该受影响。截止时间取“考试统一结束时间”和“个人开始时间 时长”的较小值交卷时后端再校验一次。自动判分只对客观题有效单选题比对答案多选题要比对集合是否完全一致漏选和错选要区分对待这个规则要在开题时写清楚。主观题保留人工批阅入口。这里我建议加一个“答题过程自动保存”的小功能学生每答一题就异步上报一次防止浏览器崩溃导致答案丢失这个细节在演示时非常能打动人。4.5 学习行为统计统计模块是我认为最容易被忽略、但对项目完整度提升最大的部分。有了它系统才不是单纯的“资料仓库”。可以做的统计有课程维度的资源完成率、作业提交率、平均分分布学生维度的累计学习时长、各科进度对比教师维度的班级活跃度。实现上基础版用几条聚合 SQL 就够了复杂一点的可以加一张按天汇总的统计表由定时任务在凌晨跑批生成避免每次打开报表都扫全表。5. 开题报告怎么写才不被退回5.1 开题报告的固定骨架与每部分的写作要点开题被退回多数不是内容不够而是逻辑链断了前面的需求分析和后面的技术方案对不上功能列表和进度安排对不上。我通常按下面这个顺序组织每一部分都回答一个明确的问题。部分要回答的问题常见扣分点选题背景与意义为什么这个场景值得做空话套话没有具体场景描述国内外研究现状别人做到什么程度了罗列产品名没有归纳出功能维度研究内容与目标你要做出什么功能列表堆砌没有主次技术路线用什么做、为什么用它只写框架名不写选型理由关键问题与难点你打算攻哪几个点难点写成“时间紧张”这类非技术问题进度安排每个阶段产出什么阶段划分过粗最后两周写测试参考文献依据是什么格式混乱数量不足写“研究内容”时我建议用“主链路 增强点”的结构先描述一条完整的主链路教师开课 → 上传内容 → 学生选课学习 → 作业考试 → 成绩统计再点出两到三个增强点实时互动、自动判分、学习行为分析。这样评审一眼就能看出你的项目有骨架也有亮点而不是一堆并列的功能名词。5.2 创新点与工作量怎么包装才算合理关于“创新点”我一直觉得这个词被用坏了。一个课程项目谈颠覆式创新不现实但谈场景化的改进完全站得住脚。比较稳的写法有三种一是针对某个具体痛点做优化比如“针对线上课堂学生注意力难保证的问题设计了随堂抢答与签到联动机制”二是做技术上的组合应用比如“将缓存与消息通道结合支撑课中高频互动”三是做体验层面的改进比如“资源进度断点续播与答题过程自动保存”。包的时候注意一个原则创新点必须能在演示中被看到。写在纸上但演示不出来的东西答辩时反而会成为追问点。至于工作量不要靠堆功能数量而是靠“每个模块都有可展示的完整闭环”。五个做通的功能远胜十五个只有列表页的功能。注意进度安排里一定要给“联调与测试”留出至少两周。我见过太多项目计划把最后一周写成“完善功能”结果联调阶段数据库字段改了三遍最后演示的是个半成品。6. 源码怎么读、怎么改成自己的6.1 拿到一套源码后的接手顺序网上现成的项目源码直接跑起来容易真正理解要按顺序来。我的接手顺序是先看依赖和配置再看表结构再看路由最后看核心业务。配置里能看出用了哪些中间件、连了什么库、端口怎么分配表结构能看出作者对业务的理解程度也能预判哪里会出问题路由列表能快速建立功能地图最后才是逐模块读业务代码。跑起来的过程中最常见的三个坎是数据库脚本执行报错多半是版本差异导致语法不兼容、依赖下载失败换镜像源或用离线包、配置项没改数据库账号、文件路径、端口冲突。这三个问题解决了八成以上能跑通。6.2 二次改造的常见方向跑通之后别急着大改先做一次“体检”。我会重点看四处有没有做权限校验很多源码只做了登录没做数据级校验、密码是不是明文如果是第一时间改掉、有没有硬编码的配置账号密码写死在代码里、删除操作是物理还是逻辑。这四处是改造性价比最高的地方。改造方向上我建议优先补“实时互动”和“统计报表”因为这两块最能体现个人工作量且不容易和别人撞车。如果时间充裕可以加一个“课程评价与反馈”模块教师能看到学生对每节课的评分和留言这个功能实现简单但业务价值清晰写进论文里也容易展开。7. 部署、联调与演示答辩的实操细节7.1 本地环境跑起来的最小路径为了少踩坑我习惯按下面的顺序推进每一步确认通了再走下一步先建库、执行建表脚本用客户端连上去确认表和索引都在。后端只启动一个空壳工程确认端口能访问、健康检查接口返回正常。接入数据库跑通一个最简单的查询接口。接入前端确认跨域配置正确、请求能打通。补上登录与拦截器确认未登录请求被正确拦截。逐个模块补业务接口每补完一个就用接口工具验证一次。最后接 WebSocket 和文件上传这两块最容易出环境问题放后面。# 打包与启动的常用命令注意把配置外置别写死在包里 mvn clean package -DskipTests java -jar target/teach-system.jar --spring.profiles.activedev7.2 答辩演示的稳定性保障演示翻车是这个项目最大的风险而且往往翻在莫名其妙的地方。我的经验是准备三份数据一份干净的初始数据用于展示新建流程、一份已经填充好的完整数据用于展示列表和统计避免现场造数据、一份降级方案录屏或截图网络或环境出问题时能顶上。演示顺序也要设计先展示最稳的登录和课程列表再展示中间态的作业提交与批阅最后展示实时互动这个亮点。不要一上来就演示最复杂的功能万一卡住后面心态会崩。另外提前把浏览器缓存清掉、把无关标签页关掉、把通知关掉这些小事在答辩现场格外重要。8. 常见问题速查与避坑清单8.1 开发阶段高频问题现象大概率原因处理方式前端请求报跨域错误后端未配置允许来源或预检请求被拦截统一在配置类里放开来源与请求方法注意携带凭证时要指定具体来源登录后立刻掉线token 未正确携带或拦截器未放行静态资源检查请求头与拦截器排除路径上传大文件失败框架与容器的大小限制未调整同时调整框架配置和容器配置两处缺一不可列表接口越翻越慢深分页扫表或缺联合索引加索引改用基于游标的分页WebSocket 连不上路径被拦截器拦下或反向代理未放行升级请求拦截器排除该路径代理配置支持协议升级考试倒计时归零还能提交只在前端做了判断后端在交卷接口重新校验时间统计数据对不上冗余计数字段与真实数据漂移加定时校正任务并记录校正日志8.2 一些踩过才知道的坑关于时间。前后端时间不一致是最隐蔽的 bug。服务端统一用 UTC 或统一时区存储返回给前端时格式化成带时区的标准字符串前端展示时再转本地时间。我吃过一次亏服务器时区是 UTC前端按本地时间显示考试开始时间整整差了八小时测试时怎么都对不上。关于并发。选课人数、抢答顺序、签到名单这三处是最典型的并发点。能用数据库唯一索引挡住的就别用代码判断能用 Redis 原子操作解决的就别用先查再写。考试名额、签到人数这类场景加一次数据库层面的唯一约束比写十个 if 都管用。关于测试数据。一定要在项目中期就开始造数据不要等到最后一天。一门课至少造三十个学生、十次作业、两次考试数据量起来了才能发现分页、统计、排序的问题。只有三条测试数据的系统看起来永远是对的。关于代码整洁度。答辩老师不一定细看代码但一定会翻。实体类命名混乱、注释全是英文模板、控制台一堆调试输出这些细节会直接影响印象分。花两个小时把命名统一、把无用的引入删掉、把配置里的测试账号清掉收益比再加一个功能高得多。关于演示用的账号。至少准备四个账号管理员、教师、学生、助教各一个密码统一但不要把密码写在幻灯片上。演示前逐个登录一次确认每个角色的菜单和权限都正常这一步能挡掉大部分现场事故。我在实际做这个项目的过程中感受最深的一点是线上的课堂永远无法完全替代线下的即时感所以系统的价值不在于把线下的流程原样搬上来而在于用技术手段补上线下做不到的部分——比如学生可以反复回看某一段讲解教师能看到每个学生的进度差异并针对性提醒作业批改结果能沉淀成可检索的历史记录。想清楚这一点功能取舍就有了依据也就不会陷进“别人有的我也要有”的功能比拼里。