企业官网建设流程全解析

每年到了春季毕业论文开题季，我都会收到同一类问题：“老师，帮我看看‘基于Spring Boot的高校科研管理系统’这个题能不能做？”我的回答通常先反问一句：“你去学校科研处或者学院科研办问过吗，他们现在用什么系统管项目、管成果？”大部分人的答案是“没问过”“学校好像没什么系统”。这就对了，这个题之所以每年都有人做，恰恰因为它是一个极其典型、极适合本科毕业设计的“业务闭环型”题目。它不用碰人工智能、不用搞分布式高并发，考察的是你对真实业务的理解、数据库设计的功底、Spring Boot工程化的基本素养，以及论文写作时把“做了什么”讲清楚的能力。

这篇博文不打算只给你一个CRUD代码集合，而是把“基于Spring Boot的高校科研管理系统”从选题、技术选型、需求拆解、数据库设计、核心流程实现到论文写作、答辩准备的完整链路走一遍。我写这些东西的来源，是这几年陆陆续续带过的几十个类似课题，以及我自己为了验证某些做法反复改过的代码和文档。如果你正打算做这个题，或者已经做了一半但觉得“只是把增删改查堆在一起”，这篇文章应该能帮你把系统从“60分”拉到“85分以上”。

1. 课题定位：为什么“老掉牙”的高校科研管理系统依然值得做

1.1 先想清楚这个题到底在考察什么

很多同学觉得“高校科研管理系统”太普通，满大街都是，显得没水平。可毕业论文考察的从来不是标题的新鲜程度，而是你对一个完整业务域的梳理能力和工程落地能力。导师和外审老师看重的，通常是以下几点你做得怎么样：

• 是否真正理解科研管理业务（而不是凭空拍脑袋造功能）。
• 数据结构设计是否合理（表之间关系、状态流转、数据冗余度）。
• 系统是否形成业务闭环（从项目申报、审核、立项、中期检查、结题，到成果登记、经费管理、统计报表）。
• 论文里的图、表、代码是否与系统实际行为一致。

如果你能把上面四点讲清楚，即便题目再常规，论文也是扎实的。反过来，如果只是把某套开源代码改个名，论文和系统对不上，答辩现场被问几句就会出问题。

我还记得当年有个学生，题目就是“高校科研项目管理系统”，但他一开始连“横向项目”“纵向项目”“结题材料”这些基本概念都说不清楚。我让他去学院科研秘书那里聊了半小时，回来之后他列的需求清单完全不一样了——加入了“经费到账记录”“结题材料附件”“成果关联项目”这些真实场景。后来他的论文评价反而不低，因为业务确实讲得圆。

1.2 高校科研管理的痛点到底是什么

你在论文的“研究背景与意义”里不能只写空话，得写出真实痛点。结合我和一线科研管理人员的交流，普遍存在这么几个问题：

• 项目申报和过程管理靠Excel。一个人手上十几份Excel表，项目名称、负责人、经费、起止时间各放一列，统计时再手动筛选，容易抄错也容易漏。
• 成果材料分散。论文、专利证书、软著证书、获奖证明，有的放在学院，有的放在老师个人手里，结题时临时找材料。
• 状态不透明。老师申报完项目，不知道审批到哪一步，只能反复去问科研秘书，甚至通过微信“催单”。
• 数据口径不统一。不同学院统计论文数量时，“一篇SCI到底算科研成果还是学术论文”都可能吵半天。

这些痛点就对应了系统里的核心模块：项目管理、成果管理、经费管理、审核流程、通知提醒、统计报表。论文的“需求分析”部分如果能基于这些痛点展开，读起来就比空泛的“提高效率、方便管理”有说服力得多。

1.3 这个课题适合谁

如果你是计算机、软件工程、信息管理相关专业的本科生，动手能力中等偏上，希望找一个“稳中求进”且能够明确写出技术深度的题目，这个课题很合适。它要求你掌握Spring Boot、MySQL、前端基础（Vue或BootStrap式模板均可），不需要太偏门的算法。同时，如果你在“权限管理”“流程状态机”“文件上传”“统计报表”这几个点上能做得完整，毕业论文的工作量就绝对够看。

2. 技术选型：Spring Boot是标准答案，细节才是分水岭

2.1 我自己的一套推荐组合

技术选型不需要花哨，但要能在论文“技术介绍”里写出选择的理由。我推荐下面这套组合，也是这几年我带这个题目用得最多的方案：

肯定有人问，为什么不用Spring Security？可以用，但Spring Security的配置复杂度对毕业设计来说偏高，而且JWT+拦截器这套方案更容易在论文里用“流程图+关键代码”讲清楚，外审老师也更容易看懂。你要记住，论文项目的核心目标不是“炫技”，而是“把一块做扎实”。

2.2 技术上最忌讳的几个方向

很多同学一上来就想着用微服务、Redis、消息队列、Docker打包全家桶，这在我眼里是大坑。不是说这些技术不好，而是本科毕业设计的开发周期和论文篇幅根本驾驭不了这么多东西，最后写出来的论文往往是“每个技术都提一嘴，每个都没讲透”，外审老师一眼就看穿。

• 不要做微服务架构。单机Spring Boot足够，强行拆服务只会增加调试成本。
• 不要过度封装前端。管理后台页面不需要工程化过度复杂的脚手架，不然光折腾环境就耗掉两周。
• 安全框架二选一即可，不要既用Shiro又用JWT又自己写拦截器。

我见过最离谱的一份代码，工程里同时集成了Shiro、Spring Security和JWT，登录逻辑绕了三层，最后演示时老出问题。这属于典型的“有能力折腾、没能力稳定”，在毕业设计里的收益极低。

2.3 Redis要不要上

如果是纯展示型管理系统，Redis不是必需品。登录状态用JWT就无状态了，缓存数据对性能的提升在这个量级下也看不出来。但如果论文里要体现“缓存设计”，可以在“统计报表”和“字典数据”两块引入Redis做简单缓存，比如统计数据缓存5分钟，刷新时清除。这个做好了一句话就能讲明白，做不好了反而变成负担。我的建议是：时间不够就放弃Redis，把权限和流程做好，价值远大于加一个缓存中间件。

3. 需求拆分：把业务流程翻译成功能清单

3.1 先画业务地图再写代码

“高校科研管理系统”这个名字听起来是一套系统，但拆开之后其实覆盖好几个子域。我在指导时一定会让同学先画一张业务地图，通常包括六个模块：

• 系统管理：用户管理、角色管理、菜单管理、操作日志。
• 项目管理：项目申报、审核、立项、中期检查、结题、项目查询。
• 成果管理：论文、专利、软著、获奖等成果登记、审核、关联项目。
• 经费管理：经费到账登记、经费使用记录、项目经费汇总。
• 通知公告：公告发布、针对特定项目/用户的站内消息提醒。
• 统计报表：项目数量统计、成果按类型/学院统计、经费汇总，用图表展示。

模块不能贪多。很多同学列了十来个大模块，最后每个模块只有“发布”“删除”两条接口，这是假工作量。论文评审老师看的是模块之间是不是有业务关系，比如“新增一条专利成果时，可以选择关联某个在研项目”，这才是体现业务理解的地方。

3.2 角色与权限矩阵

这个系统至少要有四类角色，权限矩阵需要在一开始就设计清楚：

这里有一个很容易犯的错：前端只管“有没有显示按钮”，后端接口没做权限校验。这个问题后面专门讲，但需求阶段就要明确，权限是后端强制的，前端只是“隐藏入口”。

3.3 非功能性需求别只抄网上的套话

论文里关于非功能需求，不要整段复制教科书上的“安全性、可靠性、可维护性”泛泛而谈。要有针对性，比如：

• 数据安全性：用户的密码不能明文存储，至少用MD5加盐或BCrypt。
• 操作可追溯性：项目审核、状态变更等关键操作要写审计日志，记录操作人、操作时间、变更前后状态。
• 文件限制：附件类型与大小限制，防止任意文件上传。
• 并发控制：多人同时审核同一个项目时，用状态乐观锁或SQL条件更新避免重复审核。

把这几条写实了，比空喊口号有用得多。

4. 数据库设计：外审老师最容易盯上的一章

4.1 核心表清单

一个完整的高校科研管理系统，我通常建议至少设计以下核心表。表的数量控制在14到20张之间比较合适，太少工作量不够，太多容易失控：

• t_user：用户表，字段包括id、用户名、密码、姓名、学院、职称、邮箱、手机号、状态。
• t_role：角色表。
• t_user_role：用户角色关联表。
• t_project：项目表（项目编号、名称、类型、负责人、所属学院、经费、起止时间、状态）。
• t_project_member：项目成员表（项目与教师的多对多关系）。
• t_audit_record：审核记录表（项目/成果审核的关键记录）。
• t_result_paper：论文成果表。
• t_result_patent：专利成果表。
• t_result_software：软著/获奖成果表，也可以统一成一张成果主表加类型字段。
• t_funding：经费到账记录。
• t_funding_use：经费使用记录。
• t_notice：公告表。
• t_message：站内消息表。
• t_attachment：附件表（保存文件路径、关联业务ID和类型）。
• t_dict：数据字典表（项目类型、成果类型、学院、职称等枚举数据）。
• t_log：操作日志表。

这里我个人强烈建议“成果”设计成统一主表，而不是把论文、专利、软著各建一张完全独立的表。统一主表保存共性字段（名称、类型、负责人、登记人、附件、状态），类型不同时再关联各自的扩展表，这样写统计SQL时非常方便，一句话就能group by类型。如果分别建三张表，后期要“近三年全校论文、专利、软著数量对比”时，你得写三段几乎一样的SQL再拼结果，工作量翻倍还容易错。

4.2 审核记录表为什么必须单独存在

很多第一次做这个系统的同学，会在项目表上直接加一个audit_status字段，然后审核时直接update这个字段。这个做法本身没错，但只做这一步是远远不够的。真实的科研管理流程中，一个项目可能被驳回两次、退回修改三次、换过专家重新评审，你需要回答的问题是：“这个项目最终状态是'立项通过'，但中间经历了哪些节点？是谁在什么时间做了操作？当时是哪个专家评审的？”

所以必须有一张t_audit_record表，字段建议这样设计：

• id、business_type（业务类型：项目/成果）、business_id、from_status（原状态）、to_status（新状态）、audit_user_id（审核人）、audit_comment（审核意见）、audit_time、next_expert_id（如果是评审环节，记录了给哪位专家）。

有了这张表，论文里的“审核历史”页面也好做，答辩时外审老师问“我的项目被驳回后历史记录在哪里看”，你只要打开前端的历史时间线证明一下即可。这张表的存在，本身就是你数据库设计水平的一个加分项。

4.3 关键字段设计细节

下面这些经验直接来自我调试和答辩指导时反复踩过的坑：

• 主键统一用逻辑主键id，自增或雪花ID均可。但关联表外键字段命名要统一，比如user_id、project_id，不要一会叫uid一会叫owner。
• 每张表都建议加create_by、create_time、update_time、del_flag四个字段。软删除用del_flag，这样所有列表查询条件里都要带上del_flag = 0，禁止物理删除业务数据。
• 状态字段用数字还是字符串？我建议用字符串枚举，比如项目状态：DRAFT（草稿）、PENDING_FIRST（待初审）、PENDING_REVIEW（待评审）、APPROVED（已立项）、REJECTED（已驳回）、MIDTERM（中期检查）、PENDING_FINISH（待结题）、FINISHED（已结题）、ARCHIVED（已归档）。字符串状态在代码里可读性好，日志里一目了然，定义成常量类或枚举类来管理。
• 金额字段用decimal(12,2)，不要用float或double，否则统计时会出现差额。
• 日期字段统一用datetime，存入的是标准时间。前端展示时再格式化，不要在数据库里存字符串日期。
• 文件附件路径字段用varchar(255)，保存相对路径，比如/upload/project/2025/1234_结题报告.pdf，而不是完整磁盘路径。这个细节很多同学栽过跟头。

4.4 物理外键还是逻辑外键

这是个答辩高频问题。很多教材里坚持要用外键约束来保证一致性，但实际上现在真实项目里物理外键用得越来越少，普遍采用逻辑外键，只是在应用层代码里维护关联。毕业设计里我建议你：

• 数据库表上不加物理外键约束（可以避免删除时报错、批量插入性能问题）。
• 但必须为常用外键字段建立普通索引（如user_id、project_id、business_id）。
• 在论文的数据库设计说明里，明确写一句：“本系统采用逻辑外键设计，由Service层保证数据一致性。”这句话不复杂，但能让外审老师知道你不是不会用外键，而是有设计取舍。

为了演示效果，可以在t_audit_record表里建索引的SQL这样写：

CREATE TABLE t_audit_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', business_type VARCHAR(20) NOT NULL COMMENT '业务类型: PROJECT/RESULT', business_id BIGINT NOT NULL COMMENT '业务ID', from_status VARCHAR(30) DEFAULT NULL, to_status VARCHAR(30) NOT NULL, audit_user_id BIGINT NOT NULL, audit_comment VARCHAR(500) DEFAULT NULL, audit_time DATETIME NOT NULL, INDEX idx_business_type_id (business_type, business_id), INDEX idx_audit_user (audit_user_id) ) COMMENT '审核记录表';

5. 后端工程落地：Spring Boot分层的标准姿势与关键实现

5.1 目录结构先定好

Spring Boot工程目录不要乱。我推荐按业务模块来分包，而不是所有Controller堆在一个包里。一个比较顺手的长这样：

com.example.scientific ├── controller // 接口层 │ ├── system // 用户、角色、菜单 │ ├── project // 项目相关 │ ├── result // 成果相关 │ ├── funding // 经费相关 │ ├── notice // 公告 │ └── stats // 统计 ├── service // 业务逻辑 │ ├── impl ├── mapper // MyBatis Plus的Mapper接口 ├── entity // 实体类 ├── dto // 前后端交互的数据传输对象 ├── common // 统一返回体、常量、异常处理、配置类 ├── security // JWT相关、拦截器、注解 └── utils // 工具类

这里有一个容易被忽略的点：实体类entity最好和dto分开，不要直接把数据库表实体对着前端返回。因为前端不一定需要del_flag、create_by这些字段，而且像用户查询时你不能把密码返回出去。密码字段在entity里加上@JsonIgnore或者转DTO时手动置空，这两种方法我都在项目里用过，效率上前者更省事，但后者更清晰。毕业设计代码量不大，我建议用DTO，论文里能写“避免直接暴露数据库实体结构”这个理由。

5.2 统一返回体与全局异常

前后端任何接口都统一返回下面这个结构，前端axios全部走同一个逻辑处理：

{ "code": 200, "message": "操作成功", "data": {} }

错误时返回code非200，全局异常处理器把它包装成同样的结构。论文里这张“统一返回结构”的说明几乎必写，但真正实现时要注意一个问题：文件流接口不能包成JSON返回，要用response.getOutputStream()直接输出文件或Excel，否则前端拿到的是一堆乱码。很多同学在这上面调半天，就是因为分不清普通接口和下载接口的差异。

5.3 登录鉴权链路：JWT + 拦截器 + ThreadLocal

登录流程我用文字抽出来给一个可复现的链路：

1. 用户提交用户名密码，Service层校验密码（数据库存BCrypt加密后的密文）。
2. 校验通过后，生成JWT字符串，里面只放userId和role，过期时间2小时。
3. 前端把JWT挂在每次请求的header里，key叫Authorization，值是Bearer xxx。
4. 后端写一个HandlerInterceptor，拦截需要登录的路径（/api/**），从header里解析JWT，解析成功就把用户信息放到ThreadLocal里，不成功返回401。
5. 在某些接口上用自定义注解@RequireRole("ADMIN")做角色级别的权限校验。

这个链路里有三个坑，我实际调试时都遇到过：

• 未放行/api/login和/api/register这两个路径，导致用户登录都登不进去。解决方案是在拦截器注册时用excludePathPatterns放行。
• JWT过期时间设太短，前端演示时写一会儿文章就过期，很尴尬。实际操作时把过期时间设为2小时，并做一个简单的“未授权跳转登录页”逻辑。
• 用户被禁用后，老JWT还能用，因为JWT本身无状态。解决方法是管理员禁用用户时，给用户表加一个status字段，写一个第二次校验：“每次请求时从数据库查一下用户状态，如果禁用，拦截器直接拒绝。”对毕业设计来说多查一次数据库完全无压力。

5.4 多条件组合查询与分页

项目管理列表页一定有多个筛选条件：项目名称模糊搜索、项目类型下拉、状态下拉、起止时间范围、所属学院。MyBatis Plus的LambdaQueryWrapper做这个非常顺手：

@Override public PageResult<ProjectVO> pageProjects(ProjectQueryDTO query) { LambdaQueryWrapper<Project> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Project::getStatus, query.getStatus()) .eq(query.getCollegeId() != null, Project::getCollegeId, query.getCollegeId()) .like(StrUtil.isNotBlank(query.getName()), Project::getName, query.getName()) .between(query.getStartDate() != null && query.getEndDate() != null, Project::getCreateTime, query.getStartDate(), query.getEndDate()) .orderByDesc(Project::getCreateTime); Page<Project> page = projectMapper.selectPage(new Page<>(query.getPageNum(), query.getPageSize()), wrapper); // 转VO }

注意.eq(条件, 字段, 值)这种写法里，第一个参数是控制是否拼接的条件表达式。动态条件查询最怕的就是“用户没填条件，结果数据库被全表查了一遍”，这个写法能杜绝这种情况。论文里如果要展示代码，这段逻辑非常合适，既有清晰思路又不显得是网上抄的模板。

5.5 文件上传：路径别写死在代码里

高校科研管理系统里，项目申请书、结题报告、专利证书都涉及上传。上传功能本身不难，但路径处理非常容易出问题。我把我的标准做法放在这里：

• application.yml里配置file.upload-dir=/data/upload，不要写死在代码里。
• 上传接口保存文件到uploadDir下的按日期分目录，比如/data/upload/202504/123456.pdf。
• 数据库保存相对路径/upload/202504/123456.pdf。
• 写一个资源映射配置，把/upload/**映射到本地磁盘目录file:D:/data/upload/，这样前端可以直接用相对路径访问图片或PDF。
• 文件名校验必须有：不允许../../等目录穿越字符，白名单限制常见扩展名，文件大小限制10MB。

这套配置做完，部署到服务器时只要改yml里的目录就能跑，不会出现本机能上传、部署后500的问题。

6. 核心业务闭环：状态机设计是拿高分的关键

6.1 为什么说纯CRUD拿不到好成绩

很多人的科研管理系统最后做成了“项目管理表的新增、修改、删除、列表”，每一个接口单独看都没问题，但业务上没有闭环。一个真正的项目从申报到归档，中间要经历至少五个状态变化。如果你只是把状态当作一个字段随意改，就会出现“草稿项目直接变成了已结题”“已驳回的项目还能继续走评审流程”这种逻辑漏洞。外审老师随便拿一个用例一测，系统就露馅了。

所以我在指导时一定会强调：找一个核心业务主线，把状态流转用状态机实现出来。

6.2 项目全生命周期状态表

以“纵向项目申报”为例，我设计的状态流转如下：

这张表在论文里非常有价值，外审老师一眼就能看出你理解业务。对应的后端代码，你可以写一个“状态校验器”：

private static final Map<String, List<String>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put("DRAFT", Arrays.asList("PENDING_FIRST")); TRANSITIONS.put("PENDING_FIRST", Arrays.asList("PENDING_REVIEW", "REJECTED")); TRANSITIONS.put("PENDING_REVIEW", Arrays.asList("APPROVED", "REJECTED")); // 其余状态... } public void changeStatus(String currentStatus, String targetStatus) { List<String> allowed = TRANSITIONS.get(currentStatus); if (allowed == null || !allowed.contains(targetStatus)) { throw new BusinessException("非法状态流转：" + currentStatus + " -> " + targetStatus); } }

后端所有状态更新操作都先过这个校验器，再执行SQL更新，同时写一条审核记录。这样一个简单的规则引擎就完成了，不需要Spring StateMachine这种重框架，但论文里描述成“轻量级状态机设计”完全站得住脚。

6.3 审核记录联动的业务动作

状态变更不只是改一个字段，通常伴随其他业务操作，比如：项目状态从PENDING_FIRST变成PENDING_REVIEW时，系统要给项目分配至少两位评审专家，并给专家发站内消息；项目状态变成APPROVED时，要自动生成一条经费到账预记录；项目状态变成REJECTED时，要通知申报人并附带驳回原因。

这些联动逻辑放在同一个Service方法里即可，比如projectAuditService.audit(...)，而不是让Controller里写一堆散落的代码。论文里画一张“审核时序图”，从教师提交，到秘书初审，再到专家评分，数据表和消息表的变化就能讲得清清楚楚。

6.4 统计报表怎么和状态机配合

统计报表不要单独“为了实现统计而统计”。建议把统计模块和业务状态关联起来，比如：

• 统计“各学院在研项目数量”：只统计状态为APPROVED、MIDTERM、PENDING_FINISH、FINISHED的项目。
• 统计“本年度申报项目通过率”：分母是当年提交了PENDING_FIRST及之后状态的申报数，分子是最终APPROVED的数。
• 统计“各类型成果数量”：按成果主表里type字段group by。

统计接口的SQL可以这样做，比如：

public List<Map<String, Object>> countProjectByCollege() { String sql = "SELECT c.college_name AS name, COUNT(p.id) AS value " + "FROM t_project p LEFT JOIN t_college c ON p.college_id = c.id " + "WHERE p.del_flag = 0 AND p.status IN ('APPROVED','MIDTERM','PENDING_FINISH','FINISHED') " + "GROUP BY p.college_id"; return jdbcTemplate.queryForList(sql); }

前端用ECharts画柱状图和饼图。这个模块一旦做出来，系统首页的“数据看板”就有了灵魂，论文里的截图也好看。

7. 前端工程与前后端联调：别让细节毁掉演示

7.1 页面结构与Axios封装

前端用Vue 2 + Element UI的话，建议按模块组织视图：

src ├── api // 每个后端模块的请求封装 │ ├── project.js │ ├── result.js │ └── user.js ├── router // 路由配置（含路由守卫） ├── store // 用户登录状态（Vuex） ├── views │ ├── login │ ├── dashboard // 首页看板 │ ├── project // 项目管理（列表、申报、详情、审核页面） │ ├── result // 成果管理 │ ├── funding // 经费管理 │ └── system // 用户、角色、日志 └── utils/request.js // axios实例

request.js里要做的两件事是：请求时从Vuex取token放到header；响应时统一判断code，如果是401就清掉用户信息并跳到登录页。这两件事没做好的话，联调时会发现“数据报错但页面没反应”或“登录过期后还停在当前页一直报错”。

7.2 路由守卫与按钮权限

前端路由守卫要做，但不能只做前端。最终的权限裁决必须在后端。我的习惯是：前端根据当前用户的角色动态生成可以访问的菜单，路由守卫里拦截未登录状态。按钮级别，比如“审核按钮”是否显示，可以根据角色或者后端返回的权限列表来判断，但即便按钮不显示，直接调接口时后端也会返回403，这样双重保障才合理。

7.3 联调中的四个高频坑

第一个坑是跨域。前后端分离开发时，前端跑8080，后端跑8081，接口调用会出现CORS跨域。后端写一个全局CORS配置允许前端地址即可，但只允许http://localhost:8080，不要直接allowedOrigins("*")，安全上更说得过去。

第二个坑是时间格式。后端返回的LocalDateTime默认可能有“T”字符，前端如果直接用new Date(...)解析会乱。在application.yml里配好jackson的全局时间格式，比如yyyy-MM-dd HH:mm:ss，前后端都遵守这个格式，问题就解决了。

第三个坑是分页参数名不一致。Element UI的分页组件默认叫pageNum、pageSize，后端Page参数的字段也建议叫这两个，前端就不要二次转换，避免联调时两边各改各的。

第四个坑是文件上传时的请求头。上传接口一般不需要手动加Content-Type: multipart/form-data，axios会自己生成带boundary的header。前端加了这个反而可能导致后端解析失败。这个坑排查起来很费时间，提前说清楚能省半天调试。

8. 测试、演示数据与部署：给论文一份扎实的“实锤”

8.1 单元测试怎么写才有说服力

论文里的“系统测试”不能只有“系统运行正常”一句话。我对推荐的最少测试集是：

• Service层测试：重点测状态机流转的合法与非法情况、权限判断逻辑、密码加密与校验。
• 接口层测试：用MockMvc模拟带token的请求访问受保护接口，验证未登录返回401，越权访问返回403。
• 数据校验测试：用户名空、金额为负数、非法日期等等。

一个示例性的Service层测试，可以这样写思路：

@Test void testStateTransitionFromDraftToApprovedShouldFail() { // 准备：一个DRAFT项目 // 执行：调用审核方法，targetStatus = APPROVED // 断言：抛出BusinessException，数据库状态仍为DRAFT }

这种测试代码能直接放进论文的测试文档中，说明你有“非法状态流转防护”的自动化测试，这比随便贴几个Postman截图有分量。

8.2 用Postman积累接口测试素材

Postman不是只能测接口，它还可以导出一份接口测试集合。你可以在开发过程中按模块理出一个集合，把关键请求和响应截图，这些图片可以放到论文“系统测试”章节中用做测试结论表。注意，测试数据不要编得离谱，比如“输入负数项目经费”这类用例如果你的实体字段没做校验，就不该写进测试通过列表，外审老师一旦追问就是漏洞。

8.3 演示数据要有“人间烟火气”

很多同学做出来的系统首页统计图只有三四条假数据，看起来非常寒碜。演示数据的准备要认真对待：至少造20名教师用户，分布在3个学院；20个项目，覆盖三年前到现在的时间范围，状态分散在各阶段；50条成果记录，论文、专利、软著都要有；每一个项目至少两条审核记录，时间轴合理。数据一丰富，首页图表和列表页截图都会好看很多，答辩演示时也更有底气。

这里分享一个造数据的小技巧：写一个一次性SQL脚本或Java数据初始化器，把数据以“同一个用户、同一年之内不能出现两条同名成果”这种业务一致性约束来造，避免统计时出现完全不符合逻辑的数据，比如专利数量比论文还多。初始化器代码放工程里，论文“系统数据库”章节可以提到“提供基于脚本的初始化演示数据，便于二次演示”。

8.4 部署到Linux服务器，而不是只在本地跑

如果只在本机跑通，答辩时一旦换了电脑就露怯。我建议至少在论文答辩前把系统部署到一台Linux服务器（可以用云服务器，也可以自己用虚拟机搭），然后记录部署过程。关键步骤：

• 后端用mvn clean package打出jar包。
• 创建/opt/scientific目录，把jar和application-prod.yml放进去。
• 用systemd注册服务，systemctl start scientific即可启动。
• Nginx代理前端静态文件，并把/api反向代理到后端的8081端口。
• 数据库导入schema.sql和data.sql，连接改为服务器上的MySQL。

这些步骤写进论文“系统部署”小节时，可以配上Nginx配置片段，外审老师会觉得你具备真实工程交付能力。Nginx关键配置：

server { listen 80; server_name your-domain; location / { root /opt/scientific/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

9. 论文结构、常见失败点与答辩应对

9.1 论文章节如何与系统对应

毕业设计论文的章节安排一定要跟着自己系统的实际内容走，不要完全套教材模板。我建议的目录结构是：

• 第一章 绪论：课题背景与意义、国内外研究现状、主要工作与论文结构。
• 第二章 相关技术介绍：Spring Boot、MyBatis Plus、Vue、JWT、MySQL。每个技术写为什么选，不要整段贴官方介绍。
• 第三章 系统需求分析：可行性分析、业务流程分析、功能需求、非功能需求、用例图。
• 第四章 系统设计：总体架构、功能模块设计、数据库设计、核心流程状态机设计。
• 第五章 系统实现：分模块展示页面截图、关键代码、核心逻辑讲解。
• 第六章 系统测试：测试环境、功能测试用例表、接口测试结果、性能简单测试。
• 第七章 总结与展望：客观总结所做工作，指出不足与后续改进方向。

这里最容易被外审老师批评的是第三章和第四章之间脱节。需求分析里画了完整的用例图，数据库设计里却少了对应的表。比如需求里写了“专家评审”功能，但表里没有“评审意见表”和“评分表”，这就是硬伤。写论文时务必先对着需求清单核对一遍数据库表清单。

9.2 图表选择与工作量展示

论文里建议有这几类图：

• 系统功能结构图（用树形图展示模块）。
• 角色用例图，至少给“教师用户”和“管理员”各画一张。
• 系统架构图，前后端部署结构。
• 项目审核时序图或活动图，这个图最容易体现业务理解。
• 数据库ER图，用工具从建表SQL反向生成，再调整排版。
• 每个核心页面放一张截图，总共十张左右，不要放太多。

工作量展示技巧：不要放冗长的Controller代码，而是放“状态机校验方法”“动态条件分页查询”“JWT拦截器”“文件上传映射”“统计SQL”这五类关键代码，每段控制在10到30行，配文字解释。看得懂、有思考，工作量自然就出来了。

9.3 最容易翻车的四个答辩点

第一个是“你和别人的系统有什么区别”。不要回答“我的界面更好看”，而是要说“我完整实现了项目申报到结题归档的整个状态流，并且每一次状态变更都有审计记录；统计模块与业务状态联动，能按不同口径出数据”。这个回答是实打实的。

第二个是“你的权限是怎么控制的”。要把JWT拦截器、角色注解、后端强制校验、前端菜单动态展示这四层串起来讲一遍，不要只提“用了Token”。

第三个是“如果两个秘书同时审核一个项目，会重复审核吗”。问到这个问题，你只要说审核更新SQL带了状态条件，比如UPDATE t_project SET status='PENDING_REVIEW' WHERE id=? AND status='PENDING_FIRST'，受影响行数为0说明已被处理，并配合状态机校验器，重复审核就不会发生。这个细节一旦答好，外审老师基本不会再刁难你。

第四个是“测试数据哪来的”。如果你做了一个初始化器或者脚本，就可以很正常地回答“系统内置了一套贴近真实业务的演示数据，其中包含三个学院的教师、项目、成果和经费记录，用于功能演示和图表展示”。这比支支吾吾说一句“手工加的”强太多。

我个人带过这么多论文课题，最大的体会是：这类管理系统题目的天花板其实很高，差别往往不在用了多新潮的技术，而在业务逻辑有没有闭环、数据设计经不经得起推敲、论文和系统能不能互相印证。如果你现在已经开始写代码了，不妨回看一下项目状态流转是否完整，审核记录是否留痕，统计口径是否清晰——把这三个点补扎实了，这套系统从架构到论文都会有真正拿得出手的东西。

最后再分享一个答辩前的小技巧：把你自己系统里的一条完整流程走一遍并录屏，从教师登录、申报项目、秘书初审、专家评审、立项、中期、结题到首页统计数字的变化，全程不超过三分钟。答辩时如果环境出问题，直接放录屏，同时讲清楚每一步背后对应的表结构和代码位置。这样既弥补了临场紧张，也向老师证明了你对系统每一个环节都了然于胸。祝这个课题顺利做完，希望这套思路能帮你少踩几个弯路。