线上授课系统这个题目，我每年在帮人看开题、读源码的时候都能碰上十几次。它几乎成了计算机相关专业毕设选题里的“常青树”——需求好理解、功能看着熟、网上现成的代码一大堆，看上去是个稳赚不赔的选择。但真动手做过一轮的人都知道，这个题目最容易出现的情况是：功能列表写了两页纸，代码跑起来只有登录和增删改查，答辩时被问一句“你的课堂互动怎么保证实时性”就直接卡壳。这篇内容我想从头到尾把这个项目拆一遍，包括整体架构怎么定、数据表怎么设计、核心模块怎么落地、开题报告怎么写才不被退、拿到一套源码之后按什么顺序接手改造，以及那些只有真正跑过一遍才会知道的问题。刚入门、准备做课设或毕设的读者，可以把它当成一份施工顺序表；已经写过一版、但觉得项目“很空”的读者，可以重点看数据模型和实时互动那几节，那通常是拉开差距的地方。
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 核心表结构与字段设计
我把这个系统的表分成四组：账号与组织、课程与内容、互动与作业、日志与统计。下面挑最关键的几张表说清楚字段的设计意图。
| 表名 | 关键字段 | 设计意图说明 |
|---|---|---|
| user | id, account, pwd_hash, real_name, role, status | role 用枚举区分四类角色，status 控制禁用 |
| course | id, title, teacher_id, cover, intro, status, start_at, end_at | status 表示草稿/已发布/进行中/已结课 |
| course_chapter | id, course_id, parent_id, title, sort_no, type | parent_id 自关联做两级目录，type 区分章与节 |
| chapter_resource | id, chapter_id, res_type, url, duration, size | res_type 区分视频/文档/链接，duration 用于进度计算 |
| course_enroll | id, course_id, student_id, enroll_at, status | 唯一索引 (course_id, student_id) 防重复选课 |
| homework | id, course_id, title, deadline, full_score, allow_late | allow_late 决定逾期是否可提交 |
| homework_submit | id, homework_id, student_id, content, file_url, submit_at, score, comment | 一人一份，唯一索引约束 |
| exam | id, course_id, title, start_at, end_at, duration, shuffle | duration 为限时分钟数，shuffle 控制题序随机 |
| exam_question | id, exam_id, q_type, stem, options, answer, score, sort_no | options 用 JSON 存选项，answer 存标准答案 |
| exam_record | id, exam_id, student_id, start_at, submit_at, score, status | status 表示未开始/进行中/已交卷/已阅卷 |
| study_progress | id, student_id, resource_id, progress, updated_at | 记录每个资源的观看进度百分比 |
| sign_in | id, course_id, teacher_id, start_at, expire_at, code | code 为短时有效的签到码 |
这里有几个字段值得单独说。study_progress 的 progress 用整数存百分比而不是布尔值，因为学生可能看到一半退出，下次要能续播；如果只存“看过/没看过”，体验会差很多，而这个改动成本极低。exam_record 的 start_at 很重要，它决定了这个学生这次考试的截止时间，晚于“考试结束时间”和“个人开始时间 + 时长”中较早的那个就不能再提交，这个逻辑必须在后端做，前端倒计时只是提示。
3.2 几个必须提前想清楚的设计细节
第一个细节是软删除。课程、章节这类数据一旦被引用（学生有选课记录、有作业提交），物理删除会造成大量孤儿数据。我的做法是加一个 deleted 标记位，查询时统一过滤，同时给常用查询字段建联合索引。代价是每个查询都要记得带条件，所以我通常会在 Mapper 层写一个基础查询片段，避免遗漏。
第二个细节是选课人数的统计。新手常见写法是每次查课程列表都 count 一次选课表，课程多了之后这是典型的 N+1 问题。简单有效的解决方式是给 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 这类成熟实现，几行代码的事。登录成功后签发 token，token 里带上用户 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.active=dev7.2 答辩演示的稳定性保障
演示翻车是这个项目最大的风险，而且往往翻在莫名其妙的地方。我的经验是准备三份数据：一份干净的初始数据（用于展示新建流程）、一份已经填充好的完整数据（用于展示列表和统计，避免现场造数据）、一份降级方案（录屏或截图，网络或环境出问题时能顶上）。
演示顺序也要设计：先展示最稳的登录和课程列表，再展示中间态的作业提交与批阅，最后展示实时互动这个亮点。不要一上来就演示最复杂的功能，万一卡住，后面心态会崩。另外提前把浏览器缓存清掉、把无关标签页关掉、把通知关掉，这些小事在答辩现场格外重要。
8. 常见问题速查与避坑清单
8.1 开发阶段高频问题
| 现象 | 大概率原因 | 处理方式 |
|---|---|---|
| 前端请求报跨域错误 | 后端未配置允许来源，或预检请求被拦截 | 统一在配置类里放开来源与请求方法，注意携带凭证时要指定具体来源 |
| 登录后立刻掉线 | token 未正确携带或拦截器未放行静态资源 | 检查请求头与拦截器排除路径 |
| 上传大文件失败 | 框架与容器的大小限制未调整 | 同时调整框架配置和容器配置，两处缺一不可 |
| 列表接口越翻越慢 | 深分页扫表，或缺联合索引 | 加索引，改用基于游标的分页 |
| WebSocket 连不上 | 路径被拦截器拦下，或反向代理未放行升级请求 | 拦截器排除该路径，代理配置支持协议升级 |
| 考试倒计时归零还能提交 | 只在前端做了判断 | 后端在交卷接口重新校验时间 |
| 统计数据对不上 | 冗余计数字段与真实数据漂移 | 加定时校正任务，并记录校正日志 |
8.2 一些踩过才知道的坑
关于时间。前后端时间不一致是最隐蔽的 bug。服务端统一用 UTC 或统一时区存储，返回给前端时格式化成带时区的标准字符串，前端展示时再转本地时间。我吃过一次亏：服务器时区是 UTC，前端按本地时间显示，考试开始时间整整差了八小时，测试时怎么都对不上。
关于并发。选课人数、抢答顺序、签到名单，这三处是最典型的并发点。能用数据库唯一索引挡住的，就别用代码判断；能用 Redis 原子操作解决的，就别用先查再写。考试名额、签到人数这类场景，加一次数据库层面的唯一约束，比写十个 if 都管用。
关于测试数据。一定要在项目中期就开始造数据，不要等到最后一天。一门课至少造三十个学生、十次作业、两次考试，数据量起来了才能发现分页、统计、排序的问题。只有三条测试数据的系统，看起来永远是对的。
关于代码整洁度。答辩老师不一定细看代码，但一定会翻。实体类命名混乱、注释全是英文模板、控制台一堆调试输出，这些细节会直接影响印象分。花两个小时把命名统一、把无用的引入删掉、把配置里的测试账号清掉，收益比再加一个功能高得多。
关于演示用的账号。至少准备四个账号：管理员、教师、学生、助教各一个，密码统一但不要把密码写在幻灯片上。演示前逐个登录一次，确认每个角色的菜单和权限都正常，这一步能挡掉大部分现场事故。
我在实际做这个项目的过程中感受最深的一点是：线上的课堂永远无法完全替代线下的即时感，所以系统的价值不在于把线下的流程原样搬上来，而在于用技术手段补上线下做不到的部分——比如学生可以反复回看某一段讲解，教师能看到每个学生的进度差异并针对性提醒，作业批改结果能沉淀成可检索的历史记录。想清楚这一点，功能取舍就有了依据，也就不会陷进“别人有的我也要有”的功能比拼里。