企业官网建设流程全解析

高校教师科研管理系统这个题目，在计算机毕设里属于"看着简单、做扎实不容易"的典型。很多人选它是因为觉得无非就是登录加增删改查，结果做到中期才发现，科研管理这块业务远比想象中琐碎——项目有申报、立项、中期、结题的状态流转，论文有期刊分级和收录情况要维护，专利有申请、授权、转让的节点，统计报表还要联动好几张表。这篇就围绕 Spring Boot 高校教师科研管理系统，把从选题分析、数据库设计到核心代码实现、再到论文和答辩的关键点完整过一遍，给正在做这个题目的同学一条可以直接照着走的路线。

我这些年指导过不少学生做类似题目，见过太多半路翻车的案例：有人把权限设计做得比淘宝还复杂，结果自己都理不清；有人埋头写导出功能，三天后才发现没做格式校验；还有人统计报表用循环查库，数据量一大页面直接卡死。这篇文章会把这些问题一个个摊开讲清楚，而不是只给一个"看起来能跑"的 Demo。如果你正在纠结选题，或者已经开工但卡在某个环节，这篇都适合你。基础部分我会讲得细一点，但默认你已经能跑通一个最简单的 Spring Boot Hello World，否则建议先回去补基础再来看，效率会高很多。

1. 项目定位与整体设计思路

1.1 先搞清楚科研管理系统到底管什么

拿到题目第一反应是"管理系统=登录+增删改查"，然后直接开建表，这是最大的坑。高校教师科研管理，核心业务至少包含这五块：科研项目管理、论文成果管理、专利管理、获奖管理，以及围绕这些数据的统计分析和考核报表。不同角色关心的东西完全不一样：普通教师希望快速录入自己的成果、查看申报进度；院系管理员要做审核和汇总；校级管理员要看整体科研产出，导出年度考核表。

所以设计上要优先满足"一个教师，多条成果记录，跟着状态走"这条主线。项目从申报到结题有状态流转，论文要区分已发表、已录用、被检索，专利要区分申请中、已授权、已转让。这些状态字段别用简单的删除代替业务流转，要做成状态机，哪怕初期只是用一个 status 字段加几个前端按钮控制，也比把记录直接删掉专业得多。

另外要分清主数据和业务数据。教师信息、部门信息属于主数据，稳定少变；项目、论文、专利属于业务数据，高频变化。数据库设计时这两类拆开，不要全部塞进一张大表。很多毕设论文里喜欢画一张巨大的 ER 图，把所有实体揉在一起，看着很全，实际上表之间耦合得一塌糊涂。

1.2 技术选型为什么这么定

技术栈我推荐这套：Spring Boot 2.7.x + MyBatis Plus + MySQL 8.0 + Redis + JWT + Vue 2 + Element UI。前端也可以换 Thymeleaf 做服务端渲染，如果你的前端基础比较薄弱，Thymeleaf 反而更稳，因为少了一层跨域问题。但我个人建议用前后端分离，论文里能写的东西更多，答辩时也更好讲。

Spring Boot 版本这里特别提醒一下。不要一上来就选最新的 3.x，3.x 要求 JDK 17，很多同学本机还是 JDK 8，而且不少老教程里的依赖在 3.x 下会报错。用 2.7.x 最稳，教程多、坑少、兼容性好，毕业设计完全够用。写论文的时候也别吹"采用了最新技术"，评委问一句"为什么不用 Spring Boot 3"，你答不上来反而扣分，就说"选用稳定版本以保证系统可靠性"就很好。

MyBatis Plus 的选择理由很直接：单表 CRUD 不用写 SQL，分页插件一句配置搞定，代码量比原生 MyBatis 少一半以上，对赶毕设的人来说就是救命。复杂的多表关联查询，比如统计报表那种，自己写 SQL 也不难。

Redis 在这个系统里主要用于验证码和 Token 缓存，属于锦上添花。如果时间紧，验证码用本地 Session 也行，Redis 可以不做，论文里不写这一块也不影响验收。但如果你已经会 Redis，加上去是个加分项，答辩时可以多聊几句缓存设计。

权限控制我建议用 JWT + 拦截器，不要上 Spring Security。Spring Security 的学习曲线对毕设来说太陡了，配半天过滤器链，很多人最后连登录都起不来。JWT 配合一个拦截器，几十行代码就把登录校验和角色判断做完了，效果完全够。等以后工作真需要 Spring Security 再学不迟。

1.3 功能模块怎么划分才合理

按角色和业务两条线划分模块。角色上分为系统管理员、科研管理员、普通教师三种，系统管理员管用户和基础数据，科研管理员做审核和统计，普通教师维护自己的成果。业务模块分为系统管理、教师管理、项目管理、论文管理、专利管理、获奖管理、统计报表七个模块。

这样划分的好处是：每个模块边界清晰，开发时可以按模块逐个完成，论文里也能对应出一章"系统功能设计"。很多同学喜欢把所有功能都塞给所有角色，这是错误的。普通教师不应该看到"删除他人论文"这种功能，管理员也不需要在界面上录自己的科研成果。权限控制的粒度做到"按钮级别"就够优秀了，不用再往下钻。

模块之间还有一个隐含关系要注意：项目、论文、专利、获奖都挂在教师名下，所以教师信息是这些业务表的"根"。新增业务数据时必须校验教师是否存在，这是基本的完整性设计。统计报表模块则是把这些业务数据聚合起来，按学院、按年度、按成果类型汇总，这部分是答辩时的亮点，后面我会详细讲实现。

2. 数据库设计与核心表结构

2.1 数据建模的核心思路

数据库设计是整个项目的基石，表建不好，后面写代码全是补丁。我的建议是先画业务流程图，再画 ER 图，最后建表，不要跳过前两步。科研管理系统的核心实体就六个：用户、教师、项目、论文、专利、获奖。用户和教师是一对一关系，教师和项目/论文/专利/获奖是一对多关系，项目和参与教师是多对多关系，所以需要一张项目成员关联表。

设计原则就三条：第一，每张表必须有主键，统一用自增 id，不要用业务字段当主键，比如教师工号虽然唯一，但拿来当主键在关联时非常痛苦；第二，业务状态用 tinyint 或 varchar 存，前端显示中文，不要直接把"已立项"这种中文存进数据库，后面统计和条件查询会很难受；第三，所有表都加 create_time 和 update_time 两个字段，MyBatis Plus 的自动填充功能可以省很多事，论文里也能写"系统实现了审计日志功能"。

2.2 核心表结构逐张说明

用户表 sys_user 我建议独立于教师表，因为用户关联的是登录账号和角色，教师表存的是业务信息，两者分开后，即使以后系统扩展支持学生登录，也不需要动教师表结构。核心字段：id、username、password（BCrypt 加密后存储）、real_name、role_id、teacher_id、status、create_time、update_time。密码加密不要用 MD5，用 BCrypt，Spring Security 里的 BCryptPasswordEncoder 单独引进来用就行。

教师表 teacher 字段比较多：teacher_no（工号）、name、gender、title（职称）、department、phone、email、research_direction（研究方向）、degree（学历）。这里职称和学历建议用字典表或枚举维护，不要自由输入，不然统计"教授发表论文数量"时，数据库里"教授"和"正高"并存，统计结果就是错的。

项目表 research_project 是业务核心，字段包括：project_name、project_type（纵向/横向/校级）、source（来源单位，如国家自然科学基金）、level（国家级/省部级/校级）、leader_id（负责人，关联教师表）、budget（经费，decimal 类型）、start_date、end_date、status、audit_remark（审核意见）。status 字段建议用 0-草稿、1-已申报、2-已立项、3-进行中、4-已结题、5-已驳回 这种数字枚举，配合审核意见字段记录流转历史。

论文表 paper：title、author_id（第一作者）、journal（期刊名）、journal_level（权威/核心/普通）、indexing（SCI/EI/北大核心等收录情况）、publication_date、citation_count、status（已发表/已录用）。专利表 patent：patent_name、patent_type（发明/实用新型/外观）、inventor_id、patentee（专利权人）、application_date、authorization_date、status。获奖表 award：award_name、award_level、award_type、awardee_id、award_date、issuing_unit。

2.3 项目成员关联表的特别设计

项目往往不只一个人参与，所以需要 project_member 关联表，字段有 id、project_id、teacher_id、role_in_project（负责人/参与者）、contribution_ratio（贡献度，可选）。这张表很重要，一方面支撑"某教师参与了哪些项目"的查询，另一方面也是统计教师科研工作量时的重要数据来源。

建表的时候要把索引设计好。业务查询最多的是"按教师查成果""按状态查项目""按时间范围查论文"，所以 project 表的 leader_id + status 要建联合索引，paper 表的 author_id + publication_date 要建联合索引。很多同学数据库有上万条测试数据就卡，其实就是没建索引导致的。在论文里写清楚索引设计，评委一看就知道你不是纯抄的。

外键我建议逻辑上维护，不建物理外键。物理外键在删除和更新时容易锁表，而且 MyBatis Plus 操作时经常触发外键约束报错。在业务代码里自己去校验关联关系，灵活性和性能都更好。这是企业开发的常见做法，答辩时被问"为什么不用外键"，可以理直气壮地说"考虑到性能和数据操作灵活性，采用应用层维护关联完整性"。

3. 核心功能实现实操

3.1 项目搭建与环境准备

第一步用 Spring Initializr 生成项目骨架，地址用 start.spring.io，选 Java 8、Spring Boot 2.7.x，依赖勾选 Spring Web、MySQL Driver、Lombok。生成后手动加入 MyBatis Plus、JWT、Hutool、EasyPOI 的依赖。这里不建议用阿里云的加速地址生成，那个版本库有时候滞后，还是官方源稳妥。

pom.xml 里核心依赖就这几段：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.18</version> </dependency> <dependency> <groupId>cn.afterturn</groupId> <artifactId>easypoi-spring-boot-starter</artifactId> <version>4.4.0</version> </dependency>

这里有个经典坑：jjwt 0.9.1 依赖了 JAXB，JDK 9 以上运行时会报 ClassNotFoundException，需要额外引入 jaxb-api。如果你本机是 JDK 8 就没这个问题，如果用的是 JDK 11 或 17，记得加这段：

<dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.1</version> </dependency>

application.yml 里重点配置数据源、MyBatis Plus 的驼峰映射、日志输出，以及 JWT 的密钥和过期时间。日志一定要开启 SQL 输出，调试的时候能看到 MyBatis Plus 实际执行的 SQL，不然报错了你都不知道它查的是哪张表：

mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

逻辑删除是个好功能，配置上之后，删除操作自动变成 update deleted=1，查询自动加条件。毕设系统里虽然有审核流程，但难免有误操作，逻辑删除让数据可恢复，答辩时也是一个可讲的细节。

3.2 登录认证与权限控制

登录流程是这样的：前端提交用户名密码，后端用 BCryptPasswordEncoder 校验密码，通过后生成 JWT 返回前端，前端把 Token 存在 localStorage，每次请求带上 Authorization 头。后端写一个拦截器统一校验 Token，再从 Token 里解析出 userId 和 roleId，存到 ThreadLocal 里供后续业务使用。

Token 的生成用 Hutool 的 JWTUtil 就行，非常简洁。密钥要设得长一些，至少 32 个字符，过期时间我建议设 24 小时，太短用户总被踢下线，太长不安全，毕设系统 24 小时是合理值。拦截器配置时注意放行登录接口、验证码接口，其余接口全部拦截。

角色判断建议用自定义注解 + 拦截器的方式：写一个 @RequireRole("admin") 注解，标注在需要管理员权限的 Controller 方法上，拦截器里解析注解判断当前用户角色是否匹配。这种做法的好处是权限规则紧挨着接口定义，代码可读性高，而且答辩时讲起来很清晰——"通过自定义注解实现声明式权限控制"。

具体实现时，拦截器里做两件事：校验 Token 是否有效，校验角色是否有权限。校验失败返回 401 或 403，前端统一拦截这些状态码跳转登录页。Redis 在这里的用处是存 Token 状态，可以实现"退出登录后 Token 立即失效"。没有 Redis 的话，退出登录只是前端删了 Token，服务端无法主动让 Token 失效，这是一个安全短板。

3.3 科研项目管理中的状态流转

项目管理是核心模块，重点不是 CRUD，而是状态流转。前端根据当前状态显示可操作按钮：草稿状态可以编辑和提交审核；已申报状态等待管理员审核；审核通过变成已立项；立项后可以填写中期进展；最后做结题申请。管理员端有专门的审核列表，审核时填写审核意见，通过或驳回。

后端的 Controller 接口我建议按操作命名，而不是简单暴露通用的 update 接口。例如 submitProject、approveProject、rejectProject、applyCompletion，这样每个接口的业务逻辑单一清晰，论文里也好描述。一个通用的 updateProject 接口会让前端很难控制状态流转的边界，容易出现用户跳过审核直接把项目改成已结题的情况。

代码层面，状态流转用 if-else 判断前置状态，比如只有 status=2（已立项）才能申请结题：

if (project.getStatus() != 2) { throw new ServiceException("只有已立项的项目才能申请结题"); }

这句话看着简单，但它就是状态机的核心——非法状态迁移被拦截。数据库层面再补一道防护，update 语句带上条件 status = 原状态，防止并发情况下状态被重复修改，用 MyBatis Plus 的 UpdateWrapper 实现：

LambdaUpdateWrapper<ResearchProject> wrapper = new LambdaUpdateWrapper<>(); wrapper.eq(ResearchProject::getId, id) .eq(ResearchProject::getStatus, 2) .set(ResearchProject::getStatus, 3); boolean updated = this.update(wrapper); if (!updated) { throw new ServiceException("项目状态已变化，请刷新后重试"); }

这种做法叫乐观锁，虽然毕设并发量不大，但把这套思路写进论文里，专业度立刻上了一个档次。

3.4 多条件分页查询与模糊搜索

教师端成果列表、管理员端审核列表，都是典型的"分页 + 多条件筛选"场景。MyBatis Plus 的分页插件必须手动配置，很多同学忘记配，结果分页查询返回全量数据，前端分页器失灵。配置方法很简单，写一个 MybatisPlusInterceptor 的 Bean，加上 PaginationInnerInterceptor 即可。

条件查询用 LambdaQueryWrapper，可以根据前端传入的查询参数动态拼接条件：

LambdaQueryWrapper<ResearchProject> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(name), ResearchProject::getProjectName, name) .eq(projectType != null, ResearchProject::getProjectType, projectType) .eq(status != null, ResearchProject::getStatus, status) .orderByDesc(ResearchProject::getCreateTime); Page<ResearchProject> page = this.page(new Page<>(pageNum, pageSize), wrapper);

这里有个细节：前端传空字符串时，like 条件不应该生效，所以第一个参数用 StringUtils.hasText 判断。如果是数值类型的条件，用 != null 判断。这样保证查询条件都是可选拼接，不会因为前端传了空值导致 SQL 报错。

列表查询还需要返回教师姓名，但 research_project 表里只存了 leader_id，一个简单方案是在 Service 层查询出项目列表后，再批量查询教师信息填充姓名。注意，是批量查询，不是循环查，循环查会触发 N+1 问题。用 MyBatis Plus 的 listByIds 一次性查出所有教师再组装成 Map，性能差别在数据量大了之后非常明显。

3.5 统计报表与 Excel 导出

统计报表是评分的分水岭。普通做法是统计"论文总数""项目总数"这种总数，进阶做法是按学院、按年度、按职称做交叉统计，再用 ECharts 画折线图、柱状图、饼图。实现统计功能时，直接用 MyBatis Plus 的 QueryWrapper 拼 select count 很别扭，推荐自己写 SQL，用 XML 或注解方式都行。比如按年度统计各学院论文发表数量：

@Select("SELECT d.department_name AS name, COUNT(p.id) AS value " + "FROM paper p LEFT JOIN teacher t ON p.author_id = t.id " + "LEFT JOIN department d ON t.department = d.id " + "WHERE YEAR(p.publication_date) = #{year} " + "GROUP BY d.department_name") List<Map<String, Object>> countByDepartment(@Param("year") Integer year);

返回 Map 的格式直接可以对上 ECharts 的 data 字段，前端不用二次处理。这种"后端返回聚合数据，前端直接渲染图表"的模式实现简单、效果直观，答辩时演示非常加分。

Excel 导出用 EasyPOI，写一个实体类标注 @ExcelProperty 注解，然后调用导出工具类。这里有一个隐藏坑：LocalDateTime 类型的字段导出时会报类型转换错误，EasyPOI 对 JDK8 时间类型的支持需要额外配置，最简单的方法是把日期字段统一转成 String 再导出，或者指定 exportFormat 注解属性。我建议导出专用 VO，不要直接拿实体类导出，因为实体里的逻辑删除字段、状态数字等都不应该直接展示给用户，在 VO 里做一次"翻译"，把状态数字转成中文文本，导出的表格才像人事处要的东西。

导出接口要注意内存问题，数据量几千条没问题，如果到几万条，建议分批查询写入。毕设阶段用 EasyPOI 的默认导出就够了，但代码里可以预留分批导出的结构，论文里提一句"系统支持大数据量分批导出"，又是个加分点。

4. 常见问题与排查技巧实录

4.1 数据库连接与中文乱码

这是第一个高频问题：数据库连接串没指定编码，插入中文数据变成问号。连接串一定要加 characterEncoding=utf8 和 useSSL=false，同时建表时设置 utf8mb4 字符集：

url: jdbc:mysql://localhost:3306/research_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

serverTimezone 这个参数在 MySQL 8 下必须指定，不然会报时区错误。另一个乱码场景是 EasyPOI 导出 Excel 时中文文件名乱码，解决办法是响应头设置 Content-Disposition 时做 URL 编码。前端用 Axios 接收文件流时也要设置 responseType: 'blob'，否则下载下来的文件永远是乱码的二进制文本。

4.2 MyBatis Plus 的经典坑

实体类字段名如果和数据库关键字撞了，比如有个字段叫 level，MySQL 里 level 虽然不算是严格保留字，但某些版本下会有问题。解决方法是实体字段加 @TableField("level") 注解，或者干脆把字段名改成 project_level。另一个常见问题是驼峰映射没生效，导致查询结果全是 null。检查一下配置里 map-underscore-to-camel-case 是否为 true，MyBatis Plus 默认是 true，但如果手写了 MyBatis 配置覆盖了就可能会丢。

分页查询返回 total 一直是 0，也是高频问题。原因多半是没配置分页插件。注意分页插件 Bean 要放在一个配置类里，而且不能被其他 Bean 覆盖。还有个隐蔽问题：如果使用了多个 MybatisPlusInterceptor，一定要指定顺序，PaginationInnerInterceptor 要最后添加，否则分页不生效。

4.3 前后端联调与跨域

前端项目跑在 8080 端口，后端跑在 8081 端口，直接请求必然跨域。解决办法在后端加一个全局 CORS 配置类，允许前端地址跨域访问。注意 allowedOriginPatterns 不要写成 ""，因为携带 Token 的请求不允许通配符跨域，要么写具体地址，要么用 allowedOriginPatterns("") 搭配 setAllowCredentials(true)。

联调时另一个常见问题是 JWT 的 Token 没被前端带上。很多同学后端接口单独测试没问题，前端一调用就 401，排查时先看浏览器 Network 面板里的请求头有没有 Authorization。没有的话，检查 Axios 请求拦截器是否在 headers 里设置了 Token，这是最基本的排查思路。

4.4 项目部署与环境差异

本地跑得好好的，部署到服务器就起不来，十有八九是环境差异。服务器上 MySQL 版本不一样、JDK 版本不一样、端口没放开，都是问题源。建议本地开发用 MySQL 8.0，服务器上也装 8.0，避免 5.7 和 8.0 的驱动差异。部署时用 java -jar 直接跑 jar 包，日志输出到文件，用 nohup 后台运行。要注意的是 Spring Boot 打包时一定要确保 test 阶段通过，否则 mvn package 会因为测试失败而中断。

前端部署如果是 Vue 项目，需要 npm run build 生成 dist 目录，用 Nginx 托管，同时配置反向代理把 /api 路径转发到后端端口。这里有个大坑：Vue Router 用 history 模式时，Nginx 需要配置 try_files 重写，否则刷新页面就 404。如果不想折腾 Nginx，本地演示直接用前后端分离两个进程也行，毕设答辩通常在自己电脑上演示，不一定要部署到云服务器。

4.5 常见报错速查表

5. 毕设论文写作与答辩准备

5.1 论文结构怎么安排

论文结构按学校模板来，但核心章节一般是这样：绪论（背景、意义、国内外现状）、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结。这里有两个常见的写作误区：一是相关技术介绍写太长，把 Spring Boot 的百科都抄进去了，这部分简明扼要就好，重点是"为什么选它"；二是需求分析画了一堆用例图却跟后面的设计对不上，用例图描述的每一个功能点，后面设计实现部分都要能对应上。

系统设计章节要包含总体架构图、功能模块图、数据库 ER 图和核心表结构说明。论文中最容易扣分的地方就是图表编号混乱、图与文字不符。画图不要用截图工具截代码，也不要把网上找的架构图直接拿来用，哪怕用 PowerPoint 重新画一遍也好，至少逻辑是自洽的。数据库表结构用表格列出核心字段即可，不用把每张表都贴全，太占篇幅。

5.2 答辩演示的节奏控制

答辩演示最容易犯的错是临场从登录开始慢慢点，点到核心功能时时间已经过半。正确的演示路径是：提前准备好标准测试数据，开场一句话介绍项目背景，然后直接演示最有亮点的地方——统计报表的图表展示、项目审核流转、Excel 导出。这三个功能点了之后，评委对系统的印象已经建立起来了，再快速过一遍普通 CRUD 页面收尾。

演示时要注意细节：提前关闭浏览器通知和无关程序，确保网络通畅，准备一个备用浏览器。数据库里测试数据的名字不要用"张三""李四"这种随意的，要用"王建国""李慧敏"这样像真实教师的，数据量要有梯度，比如论文按年度分布要均匀，别 2019 年一篇没有、2023 年突然五十篇，评委一眼就看出是凑的。测试数据本身也反映你对业务的理解程度。

5.3 评委最爱问的几个问题

一个必问题：系统有哪些角色，各自有什么权限？这个问题考的是需求分析是否清晰，回答时把三角色和对应功能说清楚即可。第二个高频问题：项目状态是怎么管理的？这里就把状态机设计讲一遍，重点说非法状态的拦截和乐观锁防止并发修改。第三个问题：数据量大了怎么办？从索引、分页、SQL 优化三个角度回答，哪怕你没有真正遇到大数据量，这个回答也展示了你的工程意识。

还有个容易被问到的：为什么用 JWT 不用 Session？回答要点是"前后端分离架构下 Session 不便于跨域共享，JWT 无状态、可扩展性好"，同时要诚实说"JWT 也有弊端，比如服务端无法主动失效，所以引入了 Redis 缓存 Token 黑名单"。这种回答思路，评委一听就知道你是真的自己做过，不是背的。

另外一个常见问题是：这个系统相比现有商业系统有什么优势？别吹"性能高""功能全"，就老老实实说"针对高校教师的科研管理场景做了轻量化设计，流程贴合高校实际情况，维护成本低"。毕设系统跟商业软件比功能就是比不过，强调场景匹配和落地性才是你的优势。

5.4 后续可以怎么扩展

答辩时如果被问"后续有什么展望"，或者你自己想在这个项目上继续加东西，有几个方向可以参考：引入消息通知机制，项目审核通过或驳回时发站内信或邮件通知教师；增加科研工作量自动计算功能，按论文级别、项目级别和参与角色自动算分，导出年度考核表；接入第三方学术数据库自动获取论文引用数据；前端用 Vue 3 + TypeScript 重构，配合 ECharts 做更丰富的数据可视化。

这些扩展方向不是让你全做，而是在论文的总结与展望里提一两个，表明你思考过项目的演进路径。答辩时被问"哪里可以改进"，把这段背熟就行。但注意千万别在展望里写"引入人工智能、大数据"这种与项目毫无关联的大词，评委追问起来你解释不清，反而露怯。

最后再分享一个我做毕设指导时反复强调的个人经验：不要追求模块数量多，要把核心流程做深。一个能演示完整申报、审核、结题闭环的项目管理系统，远比十个半成品模块有价值。代码不是从网上抄一段拼一段，而是每行都看懂它在干什么，遇到报错自己动手排查一遍。你能在这个过程里弄清楚 Spring Boot 的请求处理链路、MyBatis Plus 的执行机制、JWT 的校验流程，这个项目才算真正做完了，答辩的时候你心里是有底的。