企业官网建设流程全解析

去年带学生做毕业设计，几乎人手一个“XX管理系统”，SpringBoot + Vue，增删改查，页面翻来翻去就那么几套。看多了之后你会发现，这类题目真正拉开差距的往往不是代码量，而是选题里那句不起眼的限定语。就拿“面向计算机导论课题组协同教学的课程信息服务系统”这个题目来说，核心不在“课程信息服务”，而在“课题组协同”这四个字——它不是给单个老师用的课程网站，而是要支撑一个教学团队共同完成《计算机导论》这门课从排课、备课、发布、答疑到成绩评定的全部环节。这个点想明白了，系统设计的高度完全不同，论文里的研究意义也站得住脚。

技术栈选型上，Java + SpringBoot是毕设最稳妥的组合，生态成熟、资料多、答辩时不容易被问倒。Web版意味着你要有完整的前后端交互界面，控制器层、服务层、持久层、前端页面一个都不能少。后面我会把整个系统从需求拆解、数据库建模、后端核心实现，到答辩演示、部署上线完整串一遍，包括我在实际指导过程中踩过的坑和帮学生填过的坑，照着走能少走很多弯路。

1. 选题定位：这门毕设为什么值得做，协同教学到底在解决什么问题

1.1 计算机导论课程的真实痛点

《计算机导论》是几乎所有计算机相关专业大一新生的第一门专业基础课。表面上它是一门课，实际上它承担着三重任务：让学生建立对计算机学科的宏观认知、掌握基础的信息素养和工具使用能力、为后续程序设计课程打下共同的知识底座。

这门课在大学里往往是多个老师共同承担的。有的学校是按班级拆分，一个老师带两三个班；有的是按专题拆分，硬件部分、网络部分、编程入门部分由不同方向的老师轮流上台讲。无论哪种模式，教学团队内部都面临几个很现实的问题：

• 课件、实验指导书、作业题目散落在各个老师手里，没有统一的资源池
• 教学进度不统一，期中检查时才发现不同班级讲到第几章完全对不上
• 作业收集和批改方式五花八门，有的用邮件，有的用群文件，有的用在线文档
• 学生找不到答疑入口，任课老师之间互相不清楚学生问过哪些共性问题
• 期末成绩汇总靠Excel反复合并，一个班改了另一个班没改，版本管理混乱

以上任何一条单独拎出来，都能写一个“某某信息管理系统”。但它们组合在一起，就指向了一个更准确的词：协同教学支持。

1.2 “课题组协同”和普通课程网站的本质区别

很多学生看到这个题目，第一反应是做一个“课程信息发布平台”。这就会做偏。发布公告、上传课件、布置作业，这只是信息单向流动，本质上是把课程资料从线下搬到了线上，没有体现出“协同”。

你可以这样理解两者的区别：普通课程网站是“一个店长管一个超市”，他自己进货、自己摆货架、自己收银；协同教学系统是“一个团队管一条产品线”，有人负责硬件章节内容、有人负责上机实验内容、有人负责作业题库，大家分头生产内容，但最终要发布到同一个平台上，并且保持口径一致、进度可见。

具体到功能层面，“协同”至少需要支撑以下几点：

• 多教师共管一门课程：不搞“一人一套后台”，所有老师登录后看到的是同一门课的工作台
• 内容归属与审核：每个老师上传资源时明确标注章节、类型、适用班级，课程负责人可以对内容进行审核整理
• 进度可见性：每位老师维护自己所负责班级的教学进度，团队成员之间互相可见，避免讲重了或者讲漏了
• 跨班级作业与成绩汇总：教师发布作业时可以选择多个班级，学生提交后按班级分别统计，期末一键汇总
• 公共答疑区：学生提问后，团队内任何一位老师都可以回复，避免同一类型的问题在多个班级重复回答

把“协同”作为核心卖点，你的功能设计、数据库表结构、权限模型三条线就全都有了主心骨。选题的差异化也体现在这里：同样是课程管理系统，你回答的是“一门大课多个老师怎么一起教”这个具体问题。

1.3 技术栈选择的逻辑与答辩理由

SpringBoot + MyBatis-Plus + MySQL + Vue，是近年毕设最主流的组合。选它不单是因为网上的资料多，更重要的是答辩时每一层都有清晰的说服力。

SpringBoot解决了SSM时代配置繁琐的问题，内置Tomcat，打包就能跑，适合快速交付一个完整可演示的Web项目。MyBatis-Plus在MyBatis基础上做了增强，单表CRUD不用手写SQL，这对开发效率的提升非常明显，也减少了新手手写动态SQL出错的概率。前端从JSP升级到前后端分离，用Vue3 + Element Plus做后台管理界面，专业感和完成度都会往上走一个台阶。

有一点要提前想清楚：SpringBoot版本不要盲目追新。我见过不止一个学生新开项目直接用了SpringBoot 3.x，结果MyBatis-Plus、某些第三方工具类库的兼容版本还没跟上，或者JDK版本不匹配，白白折腾了两三天环境。稳妥的做法是用SpringBoot 2.7.x，JDK 1.8，MyBatis-Plus 3.5.x。这套组合经过了大量项目验证，网上踩坑帖最多，遇到问题也最容易搜到答案。

另外一个答辩时很容易被问到的问题：为什么不用前后端不分离的JSP方案？你要能答得上来——采用前后端分离是为了让前端展示层与后端业务逻辑解耦，方便后续扩展移动端或其他客户端，同时RESTful接口也更便于测试和维护。这句话背下来，比你在黑板上画十分钟架构图都管用。

2. 系统功能地图：从用户角色倒推功能模块，避免返工

2.1 三类核心角色与权限边界

做毕设最容易犯的错误是拿到题目就急着建表写代码，写到一半发现漏了某个角色的核心操作，又回头改表结构。正确的姿势是先列角色，再给每个角色划权限边界，最后倒推功能清单。

这个系统的角色权限模型其实很清晰，就三类人：

这里有一个容易被忽略的设计细节：尽管所有老师登录后都在同一个后台工作台里操作，但并不是每个老师都能修改任意内容。比如张老师上传的操作系统章节课件，李老师理论上可以查看、可以评论，但不应该能擅自删除或编辑。所以资源表必须带创建人字段，所有修改操作都要做归属校验。这类设计在代码上只是加一个判断，但它正好是答辩时体现你“系统设计思维”的素材。

2.2 需求优先级排序：哪些功能必须做，哪些是加分项

协同教学系统的功能模块可以列出来很多，但如果每个都做到完整，工作量会失控。你需要学会做减法：先保证核心闭环完整，再考虑锦上添花。

我给这个题目梳理过的功能优先级如下：

第一优先级（不做系统就不完整）

• 用户登录注册与角色权限管理
• 课程基础信息维护（课程简介、教学大纲、教师团队展示）
• 课程资源管理（课件上传、在线预览或下载、按章节分类）
• 作业管理全流程（教师发布作业指定班级 → 学生在线提交 → 教师在线批改打分 → 学生查看成绩）
• 公告发布与展示

第二优先级（体现协同特色，强烈建议做）

• 教学进度协同维护：各班级当前进度条可视化，教师可以更新自己负责班级的进度
• 公共答疑区：学生提问，教师团队共同回答，问题按章节标签归类
• 资源共享池：教师上传的资源可选择“团队共享”，形成团队内部资源库，资源支持审核上架

第三优先级（时间和精力富余时做）

• 学习数据统计：作业完成率、成绩分布、资源下载量排行
• 学生成绩Excel导入导出
• 课程评价问卷

很多学生会纠结要不要做第三优先级的内容。我的建议是：统计报表值得做，因为它直接服务于“协同教学”这个主题——负责人通过报表掌握全课程的整体教学情况，PPT演示时也非常出效果。其他的看进度再说。

2.3 原型先行：关键页面流转设计

功能清单列完之后，不要急着写代码，先用Axure或者直接手绘把关键页面画出来。不用画得很精致，重点是把页面之间的跳转关系理清楚。尤其是学生端和教师端两个后台的入口区分，以及教师端“按课程维度管理”和“按班级维度管理”的切换逻辑。

以教师端工作台为例，页面的核心应该是“课程工作台”这个概念。左侧菜单栏放章节管理、资源管理、作业管理、班级进度、答疑管理、公告管理。默认首页展示的是当前课程的整体概览——本学期已发布资源数量、待批改作业数、各班级进度对比图。这样老师一进来就能看到自己关心的教学数据，而不是冷冰冰的菜单列表。

学生端则要清爽得多：首页是今日公告和最近作业，课程资源按章节树形展示，作业模块能看到待完成和已批改两个栏目，答疑区按问题状态过滤。学生端不要堆砌太多管理功能，它是被服务的对象，不是管理者。

页面流转上有一个经典陷阱：学生提交作业之后，如果老师还没批改，学生端作业状态应当显示“已提交待批改”，成绩字段为空；批改完成后状态变更为“已批改”，成绩数字才展示。别小看这个状态机，我见过有学生的系统直接默认成绩字段为0，学生端一片红色的零分，演示的时候相当尴尬。

3. 数据库设计：协同语义如何落到表结构

3.1 核心表设计逻辑

数据库是整个系统的地基。根据上面的角色和功能分析，核心表至少需要这些：用户表、班级表、课程表、章节表、资源表、作业表、提交记录表、公告表、答疑表。

有几张表的关联关系需要特别说明。

用户与课程怎么关联？一个用户可以是学生，也可以是教师，甚至同一个账号在某门课里是负责人、在另一门课里是普通教师。所以最好用关联表来维护用户与课程、用户与班级的关系，而不是在用户表里写死角色字段。实操上可以在用户表保留一个基础角色（ROLE_ADMIN、ROLE_TEACHER、ROLE_STUDENT），再通过课程成员表精确判断用户在某一门课里的身份。这样设计虽然多写一张表的关联查询，但第一符合真实教学场景，第二答辩时能讲出设计考量。

资源表要不要分类型字段？建议要。课件、实验指导书、参考资料、视频链接，通过type字段区分。这样前端展示时可以通过不同的图标和布局增强辨识度，后台统计资源构成分布时也方便。还有一个uploader_id字段记录上传人，配套的审核状态字段可以设置成默认已通过——指导老师作为课程负责人的审核是加分场景，审核流程不是所有团队都用得上的，做成可选开关更灵活。

作业表和提交记录表为什么要分开？这是很多新手容易搞混的地方。教师发布一次作业，写了一篇作业表记录，包含标题、要求、截止时间、所属章节；学生提交作业，一条条写在提交记录表里，关联作业ID和学生ID。作业表不会因为学生提交而发生变化，提交记录表也不会存冗余的作业描述信息。两者是一对多的关系，统计分析作业完成率时，以提交记录表里查作业ID然后分组统计即可。

3.2 用MyBatis-Plus实体类反向驱动建表

关于“MyBatis-Plus根据Java实体类生成建表SQL”这个热搜点，我要先说一句实在话：MyBatis-Plus框架本身提供的是MyBatis-Plus Generator代码生成器，它能根据数据库表反向生成实体类、Mapper、Service、Controller代码，是“表驱动代码生成”，不是“实体类驱动建表”。如果你是想让实体类自动同步生成数据库表，通常会引入类似mybatis-plus-extension模块中的建表能力，或者使用像Flying-Bean这类第三方组件做实体到表的自动化。

但我个人强烈建议：毕设项目里不要依赖这种自动化建表。原因有三个：

第一，自动生成的表结构你不可控，字段名、类型、索引、默认值可能都不符合你的设计预期，后期改起来很痛苦。 第二，答辩时老师问你“这张表为什么这样设计”，你光会说“代码自动生成的”就露怯了。 第三，实体类与表结构通过手写DDL脚本管理，反而更清晰——schema.sql、data.sql放在项目里，随时可以重建库，也可以放到论文附录里展示。

正确的做法是：先根据需求设计数据库表结构，手写一套CREATE TABLE语句，然后让MyBatis-Plus的代码生成器根据这些表生成实体类、Mapper、Service、Controller。这个流程中实体类始终跟随数据库表走，语义清晰，团队协作或者答辩时也站得住脚。

MyBatis-Plus代码生成器在3.5.3之后的版本中API有一些调整，老版本的教程可能跑不通。如果你用3.5.3以上版本，生成器主类使用FastAutoGenerator即可。建议生成到独立目录后手动复制进项目，免得覆盖手写的自定义代码。

3.3 关键表字段设计的实操建议

下面给出几张核心表的字段设计思路，照着写基本不会踩坑。

CREATE TABLE course_chapter ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL COMMENT '所属课程ID', title VARCHAR(120) NOT NULL COMMENT '章节标题', chapter_order INT NOT NULL COMMENT '章节序号', description VARCHAR(500) COMMENT '章节简介', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

章节表要加chapter_order而不是直接用ID排序，因为章节顺序可能在教学过程中调整，数据库自增主键一旦插入就不能随意变更，而chapter_order可以随时通过更新语句重新排列。

CREATE TABLE course_resource ( id BIGINT PRIMARY KEY AUTO_INCREMENT, chapter_id BIGINT NOT NULL, uploader_id BIGINT NOT NULL COMMENT '上传人ID', resource_name VARCHAR(200) NOT NULL, resource_type TINYINT COMMENT '1课件 2实验指导 3参考 4视频', file_url VARCHAR(500) NOT NULL, file_size BIGINT, download_count INT DEFAULT 0, audit_status TINYINT DEFAULT 1 COMMENT '0待审核 1已通过 2已驳回', share_flag TINYINT DEFAULT 1 COMMENT '1共享 0私有', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

资源表加share_flag字段，对应我前面说的资源共享池功能。老师上传的资源如果标记为共享，整个教学团队都可在资源池中看到并选择引用到自己的班级；如果标记为私有，则只有本人和课程负责人可见。这个字段把“协同”落到了日常操作层面，不用额外做复杂的权限配置。

CREATE TABLE assignment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, chapter_id BIGINT, title VARCHAR(200) NOT NULL, content TEXT NOT NULL COMMENT '作业要求', deadline DATETIME, publish_time DATETIME, teacher_id BIGINT NOT NULL COMMENT '发布教师ID' ); CREATE TABLE assignment_submission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, assignment_id BIGINT NOT NULL, student_id BIGINT NOT NULL, submit_content TEXT, attach_url VARCHAR(500), score DECIMAL(5,2), comment VARCHAR(500) COMMENT '教师评语', status TINYINT DEFAULT 0 COMMENT '0待批改 1已批改', submit_time DATETIME, UNIQUE KEY uk_assign_student (assignment_id, student_id) );

assignment_submission表用(assignment_id, student_id)做联合唯一索引，保证同一个学生同一份作业只能提交一次。后提交的话可以走更新接口，不做并发控制的话也算够用。这个唯一约束非常重要，它是保证数据不混乱的底线。

另外提醒一句：所有关联外键，在实体类里用逻辑外键就好，不要在数据库层面真正建FOREIGN KEY约束。老师出题和批改的动作虽然频繁，但真正需要在物理层面强制外键的场景很少，更多是用户程序处理。物理外键在演示删数据或者初始化数据时也很容易被挡，纯逻辑关联足够清晰了。

4. 后端实现：SpringBoot关键模块与踩坑记录

4.1 项目结构与分层规范

SpringBoot项目结构这块，网上有太多烂大街的模板，但真正合理的包结构应该是按业务模块划分而不是按技术层划分。我建议的项目结构如下：

com.example.courseplatform ├── common // 通用返回结果、异常处理、常量、工具类 ├── config // 配置类：拦截器、跨域、文件上传配置 ├── controller // 控制层 ├── entity // 实体类 ├── mapper // 数据访问层 ├── service // 业务层接口和实现 ├── dto // 前端交互对象：入参校验、出参封装 ├── vo // 视图对象

基础包名的命名要规范，不要出现Pinyin缩写或者含义不清的包名。entity里写数据库映射实体类，dto专门承接前端传来的数据，vo负责组装返回给前端的数据，三层各司其职。这样在答辩时如果老师翻看代码，会看到一个结构清爽、职责明确的工程，印象分会差别很大。

另外，所有的接口返回类型统一用Result<T>包装，包含code、message、data三个字段。成功返200，业务异常返特定的业务码。不要一会儿返回Map、一会儿返回实体类、一会儿返回String，那种接口风格自己调试都嫌乱。

4.2 登录鉴权与角色权限：最容易返工的点

SpringBoot的登录鉴权方案主要有三种：Session、JWT、集成Spring Security + JWT。毕设项目怎么选？

如果你追求最高效率，用JWT + 拦截器就够了。登录成功后生成token返回前端，前端把token存起来，每次请求带上Authorization请求头，后端拦截器解析token、查询出用户信息、塞进ThreadLocal或者请求属性里供后续使用。

理由很简单：Spring Security的学习曲线对毕设来说有点陡峭，光是一个“过滤链放行哪些路径、拦截哪些路径”就能熬掉好几天。而JWT + 拦截器几十行代码就搞定，原理也容易向答辩老师讲清楚。如果你非要集成Spring Security，至少要留出一周时间专门调试登录失效、白名单路径、密码加密策略这些细节。

实现上有一个容易忽略的点：token过期时间。有的学生设计成24小时过期，演示的时候登录一次用一天，看似方便，但答辩当天万一你提前一天配置的数据因为token过期失效了，现场就很紧张。建议处理如下：

• token有效期设置为7天
• 登录接口加“记住我”选项，勾选后有效期延长到30天
• 拦截器放行登录、注册等白名单路径

还有角色的动态权限判断。比如教师访问资源列表，只能看到自己上传的资源外加共享资源，那在Mapper层就需要根据参数动态拼接AND条件。用MyBatis-Plus的LambdaQueryWrapper可以这样处理：

LambdaQueryWrapper<CourseResource> wrapper = Wrappers.lambdaQuery(); wrapper.eq(CourseResource::getCourseId, courseId); wrapper.and(wq -> wq.eq(CourseResource::getUploaderId, currentUserId) .or() .eq(CourseResource::getShareFlag, 1));

注意and方法嵌套的应用，它是MyBatis-Plus构造复杂条件查询的关键，很多人只会在简单条件上写写eq，遇到这种场景就抓瞎去手写SQL了。

4.3 文件上传与课件管理：本地路径、访问映射与安全

课程信息服务系统必然涉及课件、作业附件的上传和访问。这个话题涉及的问题不少，但规模不大。

开发阶段最省事的方案是把文件保存到本地磁盘的某个目录，然后配置静态资源映射让SpringBoot能够把它们映射为可访问的URL。做法很简单，在application.yml里这样配：

spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB file: upload-dir: ./upload

然后写一个配置类完成本地路径到URL的映射：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Value("${file.upload-dir}") private String uploadDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceHandler("file:" + uploadDir + "/"); } }

这段配置踩过一个坑：Windows环境下file:后面要拼绝对路径，比如file:D:/project/upload/；Linux下路径末尾的斜杠不能省略。如果路径写不规范，静态资源会404，而且控制台不一定有明显报错。

文件上传后保存记录时，数据库里的file_url字段保存相对路径，比如/files/2025/05/xxx.pdf，不要存完整地址。这样以后如果换了域名或者迁移了服务器，数据表不用改，前端拼域名就能访问。答辩前的演示环境经常在笔记本上，这个习惯能帮你省掉很多来回改数据的琐碎操作。

另外课程平台的课件大多是PDF或者Office文件，浏览器直接打开PDF可以，Word的文件则需要下载到本地。前端兼容方案是：PDF文件用<iframe>或者pdf.js在线预览，其他类型直接给下载链接。有条件的话还可以接一个在线文档服务做预览，但毕设不强制。

关于文件类型校验，后端上传接口一定要加校验。别只靠前端限制后缀名就完事，用postman绕过前端直接往接口里传一个.jsp或者.jspx文件，如果后端不校验，理论上可以上传可执行脚本。最简单的方式是用FilenameUtils.getExtension判断白名单后缀：

String ext = FilenameUtils.getExtension(file.getOriginalFilename()); Set<String> allowedExt = new HashSet<>(Arrays.asList("pdf", "ppt", "pptx", "doc", "docx", "zip", "rar", "jpg", "png")); if (!allowedExt.contains(ext.toLowerCase())) { throw new BusinessException("不支持的文件类型"); }

同时，上传文件要重命名，不要直接用原始文件名保存。可以使用UUID拼接扩展名，既能避免文件名冲突，也可以防止中文文件名在跨平台时引发的编码问题。

4.4 多教师协同场景的事务边界

协同教学带来的一个典型事务问题是：教师发布作业的时候，勾选了三个班级，后端要同时往班级作业关联表里插三条记录；如果插到第二条失败了，怎么办？答案必须是“前面插入的也回滚”，这就是事务的原子性。

SpringBoot中加事务很简单，在Service实现类方法上标注@Transactional即可。但要注意几个使用细节：

• @Transactional加在public方法上才生效，私有方法是不行的
• 事务方法之间通过this直接调用（同类内部调用），事务会失效。解决方法是把方法放到不同的Service里通过注入调用，或者自己注入本类对象代理调用
• RuntimeException默认回滚，而检查异常默认不回滚。需要回滚时指定rollbackFor = Exception.class

协同教学系统中这类场景不止作业发布一个。还有：教师发布公告时同时推送给多个班级、课程负责人调整团队成员时同步更新班级负责人、删除课程时级联清理资源和作业等。凡是一次操作涉及多个表写入的，都要考虑事务注解。

还有分布式锁这些，毕设阶段基本用不上，不必为了显得高级去引一套分布式方案，那反而画蛇添足。单体应用加好事务，把逻辑梳理清楚，足够应付演示和答辩。

5. 答辩导向的亮点设计与演示脚本

5.1 三个最拿得出手的“协同”亮点

毕设答辩时间通常只有五到十分钟，如何让老师在短时间内get到你系统的核心价值？答案是准备两三个有记忆点的亮点，最好每个亮点都配一条演示路径。

亮点一：可视化的多班级教学进度墙

在教师工作台首页，以班级为维度展示各班级的当前进度。每个班级对应一个进度条，显示“已讲章节数/总章节数”。教师更新进度时选择“我负责的班级 + 当前章节号”，进度墙即时刷新。这个功能直观呈现了“协同教学”的价值——教学团队负责人不看Excel，不用一个个问，打开系统就一目了然。

演示时的话术可以这么讲：“系统当前有软件241、软件242两个班，张老师更新了241班讲到第5章，李老师更新了242班讲到第4章，负责人通过首页进度墙可以快速发现两个班的教学进度差异，及时调整教学安排。”

亮点二：资源共享池 + 审核上架机制

教师上传资源时选择“共享到团队资源池”，提交后落到待审核状态；课程负责人审核通过后，资源进入资源池展示区，所有教师都可以查看、引用到自己班级。这个流程模拟了真实教研组的工作方式，既体现协同，又体现规范。

演示时建议走完整链路：用教师账号上传一个资源并勾选共享 → 切换负责人账号 → 在审核列表中通过该资源 → 回到教师端资源池看到已上架资源。三步操作，把审核流、角色权限、状态流转都串起来。

亮点三：基于协同的作业数据统计

作业完成率和成绩分布统计是很多课程系统都会做的，但协同场景下的统计可以更进一步：不仅按班级统计，还能按章节统计、按教师统计。比如“软件241班关于‘网络基础’章节的作业平均分明显低于其他班级”，这个信息可以让相应章节的教学负责人去复盘课件和讲解方式。

这个亮点放到论文的“系统测试与分析”部分也是一个很好的数据素材，避免测试章节只有冷冰冰的“系统运行正常”几个字。

5.2 演示脚本该怎么准备

答辩成败一半在演示是否顺畅。建议准备三条核心演示链路，每条控制在两分钟以内，练到形成肌肉记忆。

第一条链路：学生视角。学生登录 → 查看今日公告 → 浏览课程章节资源 → 下载课件 → 查看作业任务 → 提交作业。这条链路可以放在演示开头，让老师先明白系统的基本服务对象和使用方式。

第二条链路：教师视角。教师登录 → 进入工作台 → 查看整体进度概览 → 上传课件到某章节 → 创建作业并指定班级 → 在待批改列表查看学生提交 → 打分写评语。

第三条链路：协同与审核视角。负责人登录 → 查看教学进度墙 → 查看团队资源池 → 审核教师上传的资源 → 查看全课程成绩统计报表。

答辩前至少完整排练三遍，重点关注两类问题：一类是网络环境不好时页面加载慢怎么应对，另一类是账号密码输错、弹窗提示等意外情况的快速处理。提前把账号密码写在演示文档备注里，万一现场手抖输错还能快速恢复。

6. 部署与收尾：从本地到可演示的完整链路

6.1 环境规划与打包部署

开发阶段用mvn spring-boot:run和前端npm run dev跑就行。但答辩前最好部署到一个稳定的环境上，不要用IDEA启动的方式做演示，万一答辩现场IDEA抽风，或者临时内存不足，整个演示就卡壳了。

推荐两种部署方案：

方案一：云服务器 + Docker部署。如果自己有云服务器，用mvn package打一个jar包，写一个简单的Dockerfile，把MySQL、Redis（如果用到）一起通过docker-compose编排起来，部署在服务器上。答辩时直接公网访问，稳定性和仪式感都拉满。这一套流程在简历上写“熟悉项目部署上线流程”的时候也有底气。

方案二：本机 + 手动启动。没有服务器的话，至少在答辩前把后端打成jar包，用命令行java -jar启动，前端构建成静态文件放到Nginx或者直接由后端托管。不要把IDEA作为启动依赖。

打包前的检查清单：

• 数据库连接配置改成部署环境的实际值，放到application-prod.yml里，千万别开发环境、生产环境混用
• 前端接口地址改成服务器IP或域名，不要留着localhost
• 关闭spring-boot-devtools自动重启插件
• 检查upload目录的读写权限，Linux下目录权限不够会导致上传失败
• 用mvn clean package -DskipTests打出来的jar放在一个干净目录里，启动日志重定向到文件，方便排查

6.2 毕设论文与代码的一致性陷阱

最后说一个论文答辩时的隐形扣分点：论文内容与实际系统不一致。每年我都会遇到下面这些情况：

• 论文数据库设计章节画了8张表，实际系统里建了12张表
• 论文功能模块图里有“在线考试”，实际代码里根本没有这个模块，或者是半成品
• 论文测试章节写“系统性能良好，支持100并发”，但没有任何压测证据
• 论文技术路线写的是SpringBoot 3.0，代码里pom.xml还是2.7

这些不一致的问题一旦被答辩老师发现，伤害是成倍的——它会直接打击老师对你整个论文的信任度，哪怕代码本身很干净，也会被打上“态度不认真”的标签。

建议在定稿前做一次规范的自检：按论文目录逐章核对代码，确理论文里出现的每个图表、每个功能、每个数据都能在系统里找到对应实现。做不到的功能趁早从论文里删掉，不要写“展望”里虚晃一枪，为了撑字数留隐患。

另外多提一句论文里的ER图，尽量用工具自动导出数据库结构再加工，不要手画。手绘的ER图一旦和实际表结构有出入，看起来特别碍眼。PowerDesigner、Navicat的模型功能或者dbschemacrawler这类工具都能快速生成比较规范的关系图，稍作美化就能放进论文。

6.3 答辩前夜的最后检查

每次带学生答辩前，我基本都会让他们做一遍同样的最后检查，这里直接分享出来：

• 本地和部署环境各跑一遍三条核心演示链路，确认不依赖开发工具
• 清空测试垃圾数据，把演示数据重新造一遍。造数据要贴近真实，比如学生姓名用“张伟、李娜”这种常见名字，班级叫“软件241班”，作业成绩分布要自然，不要全是满分
• 准备一个“系统异常应对清单”：如果文件预览失败怎么办、如果评分提交时网络超时怎么办、如果某个账号突然登录不上怎么办。列好对应的解决办法，心里有底
• 充好电、提前去答辩教室测试投影、确认网络可用

还有一个小建议：把数据库的dump.sql文件随项目一起存云盘或者U盘备份。答辩现场万一数据被改出问题，最快恢复的方式是重新导入一份干净的数据，而不是在现场手工去改某条记录。

整体做下来你会发现，“课程信息服务系统”这种题目真正的含金量不在技术难度，而在于你是否把一个具体的教学场景理解透了，并且把理解转化成合理的功能设计和稳定可演示的系统。协同教学这层内核咬住了，从开题、设计、开发到答辩，每一步都有明确的方向感。照着这个思路走，拿个不错的成绩是完全有把握的。