企业官网建设流程全解析

简介：本资源是一套面向高校计算机专业本科生的毕业设计级项目，聚焦大学生心理健康管理场景，基于SpringBoot框架实现完整Web应用系统，适用于课程设计、毕设开题与系统开发实践。资源包共846个文件，涵盖149个Java后端核心类、69个Vue前端组件、157个JavaScript交互逻辑、162个SVG图标及配套CSS/HTML/SQL等资源，整体压缩后23.78MB，结构清晰，含build、run、install三类批处理脚本，便于本地快速部署调试。已有238人学习下载，可直接获取包含心理测评引擎、在线咨询模块、个性化辅导计划生成、心理健康课程管理等全功能源码，同时提供标准化数据库脚本与典型心理量表问卷配置，具备真实业务逻辑与工程化分层架构，适合Java全栈开发入门到进阶者参考学习。

1. 从论文选题到系统落地：大学生心理健康管理这块硬骨头该怎么啃

每年到了毕业季，总有一大批计算机相关专业的学生在选题系统里扒拉着“大学生心理健康管理”这类题目。说实在的，这个选题这些年热度一直很高，原因也很直白：一是学校层面有真实需求，二是业务逻辑不算复杂到失控，三是答辩时好讲清楚。但真正动手做的时候，很多人会发现自己低估了它——表面上看就是一个增删改查，实际上心理健康领域的业务规则、数据敏感性、角色权限设计，每一块都能让论文内容丰富好几个档次。

我见过太多同学把这类题目做成了“学生信息管理+一篇心理文章列表”，答辩时被老师一问“你的系统在心理健康干预方面到底做了什么”，就支支吾吾说不出话来。所以这篇博文我想从一个更适合做毕业论文的角度，把这个系统从头到尾拆一遍：需求怎么分析、技术栈怎么选、数据库表怎么设计、核心业务流程怎么实现、论文结构怎么搭、答辩时哪些点容易被追问。针对的是正在准备毕业设计或者想拿这个题目练手SpringBoot项目的同学，如果你已经有一定Java基础但没完整做过一个项目，这篇文章正好能帮你把零散的知识串起来。

先说一下我自己的情况：前几年带过不少用SpringBoot做毕设的学生，也帮人审过这个题目的论文，踩过的坑、被答辩老师怼过的点、代码里藏得比较深的问题，我都见过不少。这篇文章里的内容，全是从实际经验和常见问题里提炼出来的，不是那种从需求文档抄到设计文档、再从设计文档抄到论文里的空话。

2. 需求分析做到什么程度，论文才不会被质疑

2.1 别把“用户管理”当核心卖点，心理健康才是

很多同学拿到这个题目，第一反应就是“管理员管理学生、学生看看文章”，结果整个系统的业务闭环是断的。为了搞明白这个问题，先别急着写代码，先回答三个问题：学生在这个系统里到底要完成什么心理服务？谁在背后提供服务？服务过程产生了哪些数据、这些数据如何被安全使用？

比较合理的业务模型是这样的：学生登录系统后，可以完成心理测评（比如SCL-90症状自评量表、SDS抑郁自评量表）、查看测评报告、在线预约心理咨询、浏览心理健康文章、给咨询师留言。咨询师角色可以查看学生的测评结果、处理预约请求、回复留言。管理员负责维护学生信息、管理咨询师账号、审核文章、查看系统统计数据。这样的结构就是一条完整的服务链，而不是零散的功能点。

为什么我特别强调测评这条线？因为它是整个系统的数据核心。测评量表是心理服务里最标准化、最容易用系统实现的部分，量表题目、选项分值、计分规则、结果解释，这些都可以做成可配置的数据表。系统替咨询师完成了初筛工作，咨询师拿到的是结构化的测评报告，这个价值在论文里非常好讲，也符合“管理”这个词的本质——不只是管理人，更是管理数据、管理服务流程。

2.2 角色权限不设计清楚，后面所有功能都会乱套

大学生心理健康管理系统的用户角色，我建议至少拆成三类：学生、咨询师、管理员。如果有余力，还可以加一个辅导员角色，只允许查看本学院学生的匿名统计数据。角色拆得越清楚，后面的权限设计就越有东西可写，论文的创新点也能多一点。

从权限粒度上说，学生只能看自己的测评记录和报告，咨询师可以看权限范围内学生的测评记录但不能查看学生手机号等敏感联系方式，管理员负责系统配置和账号管理但不应该随意查看具体测评答案。这种“数据级权限”的需求，在答辩时是很好的加分项，因为很多毕设系统只有菜单级权限（哪些角色能进哪些页面），很少有数据级权限（同一页面里不同角色看到的数据范围不同）。

这里还要特别注意一个点：心理健康数据属于敏感数据，系统设计时必须考虑隐私保护。即使毕设阶段不需要真做等保合规，你也应该在论文里写清楚数据加密存储、日志脱敏这些设计思路。这个点现在答辩老师越来越爱问，因为整个行业都在强调数据安全，你提前考虑到了，就比别人高出一个段位。

3. 技术选型背后的取舍：为什么是SpringBoot、MyBatis-Plus和MySQL

3.1 SpringBoot不是“因为大家都在用”才选的

这个题目用SpringBoot做后端，基本上是绝大多数人的选择，但论文里如果你只写一句“SpringBoot简化了配置，提高了开发效率”，那就太单薄了。你需要讲清楚SpringBoot在这个项目里到底解决了什么实际问题。

心理健康管理系统的后端，涉及的功能模块很多：用户认证、测评业务、预约业务、内容管理、数据统计。如果还用传统的SSH或者SSM架构，光是XML配置就要写一大堆，而且不同模块之间的配置还容易互相干扰。SpringBoot的自动配置机制，或者说约定优于配置的思想，让我们可以把精力集中在业务代码上。最直观的例子是数据源配置：在SpringBoot里，只要在application.yml里写好数据库连接信息，引入对应的starter依赖，数据源就自动配好了；换成之前的Spring MVC项目，你得写一个专门的DataSource配置文件，再配置MyBatis的SqlSessionFactory和MapperScannerConfigurer，稍不注意就报各种奇怪的初始化错误。

另外一个很实际的点是：SpringBoot自带内嵌Tomcat，打包成可执行的JAR就能跑起来。这对毕设部署演示来说太重要了，你不用在答辩教室的电脑上现装Tomcat、改端口、配环境，一条java -jar命令就能把系统拉起来。别忘了论文里把“内嵌容器、独立运行”作为选型理由之一写进去，答辩老师会觉得你确实动手跑过。

3.2 MyBatis-Plus让数据访问层从“体力活”变成“技术活”

持久层框架的选择上，MyBatis和MyBatis-Plus是主流。我个人的建议是直接用MyBatis-Plus，理由有两条：第一，它的BaseMapper内置了单表CRUD方法，像用户表、量表题目表、文章表这些基础的增删改查，你完全不需要手写SQL，省下来的时间可以用来写更复杂的统计查询；第二，它支持条件构造器，动态查询的代码非常简洁。

举个例子，学生端查询可见的测评量表，需要满足“状态为启用”这个条件。用MyBatis-Plus的LambdaQueryWrapper写起来就是这样：

LambdaQueryWrapper<Questionnaire> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Questionnaire::getStatus, 1) .orderByDesc(Questionnaire::getSortOrder); List<Questionnaire> list = questionnaireMapper.selectList(wrapper);

不用拼接字符串，不用写XML，代码可读性高，后期维护也舒服。但要注意，MyBatis-Plus只是帮你处理了单表操作，多表关联的复杂查询（比如统计某个咨询师名下的预约总数、按学院分组统计测评参与率）还是要写自定义SQL。这部分在论文里反而值得多写几笔，因为复杂SQL能体现数据库设计功底。

3.3 前端方案选型：不是只有前后端分离一条路

“SpringBoot + Vue前后端分离”是现在很多毕设的标配，但说实话，这个方案放在心理健康管理系统上，未必是最优解。如果你的重点是想把后端业务逻辑和论文深度做扎实，前端用服务端渲染的Thymeleaf模板引擎反而更省事。SpringBoot对Thymeleaf的支持非常完善，页面直接嵌套在SpringBoot项目里，不用考虑跨域、不用单独启动前端项目、不用处理Token传递，部署时也只要打一个包。

如果你确实想做前后端分离，让项目看起来更“现代”，那就必须把跨域问题、登录认证方式（JWT还是Session）、接口文档管理（Swagger/Knife4j）这些配套内容都做全。我见过不少选前后端分离的同学，前端写得一塌糊涂，后端接口也设计得没有章法，最后两个端加起来反而不如一个Thymeleaf项目完整。

我的建议是：如果你的前端基础一般，老老实实用Thymeleaf + Bootstrap或Layui，把后端做深做透；如果你前后端都玩得转，再考虑Vue分离方案，并且一定要在论文里单独开一章讲接口设计规范。毕设的核心目标是拿到学位，不是为了炫技，稳才是第一位的。

4. 数据库设计决定系统上限：表结构怎么划分才算合格

4.1 核心表拆解：从用户表到测评记录表

数据库设计这块，我直接把我认为比较合理的一套表结构分享出来，你们可以根据自己的业务做增删。核心表大概有这些：用户表、角色表、用户角色关联表、量表分类表、量表信息表、量表题目表、量表选项表、测评记录表、测评答案表、咨询师信息表、预约时段表、预约记录表、心理文章分类表、心理文章表、留言表、系统公告表。

用户表要注意的细节很多。除了常规的用户名、密码、姓名、学号、学院、专业、班级之外，我建议你加一个逻辑删除字段deleted，用MyBatis-Plus的@TableLogic注解处理，这样用户删除都是假删除，数据不会物理消失，在论文里可以解释为“保留审计痕迹”。密码字段存的一定是加密后的密文，不要用MD5——MD5现在太容易被字典撞库了，用Spring Security里的BCryptPasswordEncoder会更稳妥。另外，性别、邮箱、手机号这些字段不是核心，但建议保留，因为心理测评报告里常需要按性别做统计分析，你前期不采集这些数据，后面想做统计报表就做不了。

测评相关的表是整个系统最核心的部分。量表信息表存量表名称、类型（SCL-90、SDS、SAS等）、题目数量、计分方式（五级计分还是四级计分）、适用人群、状态。量表题目表通过量表ID关联，存题目内容和所属维度。这里有一个关键设计：很多量表是有维度划分的，比如SCL-90就有躯体化、强迫症状、人际关系敏感等九个维度，每道题目属于某个维度，最后统计报告要按维度分别计算得分。所以题目表里必须有一个dimension字段，否则你做完量表之后没法生成结构化报告。

测评记录表和测评答案表的关联关系也同样重要。测评记录表记录某位学生在某个时间做了哪份量表、总得分、状态（进行中/已完成），测评答案表则一行一行地记录每道题的选择结果和对应分值。这样设计的目的是：一份测评报告可以追溯到每一道题的具体回答，咨询师能看到学生的作答明细，而不是只有一个总分。这对心理服务的专业性至关重要，答辩时值得专门讲。

4.2 预约模块的防冲突设计：乐观锁还是唯一索引

心理咨询预约模块是整个系统里最容易出并发问题的地方。一个咨询师一天只能安排有限的时间段，如果两个学生同时抢同一个时段，系统必须保证只有一个能预约成功。这时候如果你只在业务代码里判断“时段是否已被预约”，理论上会有并发漏洞：两个请求同时读到“未预约”，然后同时写入预约记录，结果就是超卖。

最简单的解决方案有两种。第一种是在预约时段表里加一个唯一索引，索引字段是咨询师ID和时间段，这样数据库层面就拒绝了重复预约。第二种是用乐观锁，在时段表里加一个version字段，更新时带上版本号条件，更新影响行数为0则说明已被别人抢先。两种方案在论文里都可以写，我建议写唯一索引为主，因为更简单直观，答辩时也更好解释。

预约时段表的字段设计也值得展开。不要只存一个开始时间，要把时间细化成日期、开始时间、结束时间，或者用一个时间段编号关联预设的时段（比如上午一二节课、下午三四节课）。预约记录表里除了会话所属的咨询师ID、学生ID、时段ID，还要有状态字段：待确认、已确认、已完成、已取消。学生提交预约后，咨询师可以确认或者驳回，驳回要填写理由，这个流程闭环在论文里非常有讲头，因为体现的是“需求分析到位”。

4.3 表关系图中最容易犯的错误：没有关联就没有故事

很多同学画ER图的时候，只是把表画出来，然后用线连起来，但连线表示什么关系、关系基数是多少，完全说不清楚。比如用户表和测评记录表之间是什么关系？一个用户可以做多次测评，一条测评记录属于一个用户，这就是一对多关系。测评记录表和测评答案表是一对多，量表信息表和量表题目表也是一对多。理解这些关系，不只是为了画图好看，更是为了写SQL时知道怎么JOIN。

我见过一个很典型的错误：测评记录表里存了用户名（字符串），而不是用户ID。表面上看没问题，但一旦用户改了自己的昵称，历史测评记录里的用户名就跟着错了，统计报表也会乱。正确的做法是存用户ID，需要显示用户名时再关联用户表去查。这就是“范式化设计”的实践——虽然在线交易系统更强调反范式化，但心理健康管理系统这种以数据分析和报表为主的场景，规范化处理好于冗余存储。

5. 核心业务逻辑实现指南：认证、测评计分、报表与权限

5.1 登录认证：从Session到JWT的选型

认证方案的选择直接影响到整个系统的架构。如果前端是Thymeleaf，用Session认证就好，Spring Security提供了一套完整的Session管理机制，登录成功后把用户信息放在Session里，页面通过Thymeleaf模板取用户数据，非常简单。如果是前后端分离，JWT（JSON Web Token）会是更合适的选择，登录成功后后端返回一个Token，前端每次请求都带上。

JWT方案虽然看起来高大上，但有一个容易被忽略的坑：Token一旦签发，在有效期内无法主动失效。如果某个学生的账号被管理员禁用，但它的Token还有效，它依然可以继续访问接口。解决办法是引入Redis存储Token黑名单，或者设置较短的Token有效期、结合刷新Token机制。考虑到毕设项目的实际规模，如果你用JWT方案，我建议把Token有效期设置为2小时，同时提供一个退出登录接口把Token加入黑名单——哪怕这个黑名单只是内存里的一个ConcurrentHashMap，也比什么都不做强。

Spring Security配置方面，我重点提醒两个地方。第一，放行路径别乱放，登录接口、验证码接口、静态资源可以放行，但测评提交、预约申请、数据分析这些接口必须认证后才能访问。第二，密码加密一定要用BCrypt，不要用明文或者简单MD5。在配置类里你只需要这样写：

@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }

注册的时候用passwordEncoder.encode(rawPassword)加密存库，登录时用passwordEncoder.matches(rawPassword, encodedPassword)校验。这个做法在论文里可以写一小段“安全设计”，答辩时被问到的概率很高。

5.2 测评计分逻辑：你的计分代码能通过数据验证吗

心理测评的计分是整个系统最核心的算法逻辑，没有之一。好的计分模块应该是可配置、可复度的，而不是把计分规则写死在代码里。不同量表的计分规则不一样：SCL-90是五级计分（没有=1分，很轻=2分，中度=3分，偏重=4分，严重=5分），SDS是四级计分，部分量表还有反向计分题。反向计分题是什么意思？就是某些题目在设定上与其他题目的方向相反，例如“我觉得生活很有意义”这道题，选“没有或很少时间”反而应该得4分，选“绝大部分或全部时间”得1分。

所以计分模块的设计要点是：量表题目表里要有一个字段标记这道题是否反向计分，计分时读到这个标记就把原始分翻转。具体实现可以这样设计：

public Map<String, Object> calculateScore(List<AnswerItem> answers, Questionnaire questionnaire) { Map<String, Double> dimensionScores = new HashMap<>(); Map<String, List<AnswerItem>> grouped = answers.stream() .collect(Collectors.groupingBy(AnswerItem::getDimension)); for (Map.Entry<String, List<AnswerItem>> entry : grouped.entrySet()) { double total = 0.0; for (AnswerItem item : entry.getValue()) { if (item.getReverseFlag() == 1) { total += reverseScore(item.getScore(), questionnaire.getMaxScore()); } else { total += item.getScore(); } } dimensionScores.put(entry.getKey(), total / entry.getValue().size()); } return dimensionScores; } private int reverseScore(int score, int maxScore) { return maxScore + 1 - score; }

这里用平均分还是用总分，取决于量表本身的计分标准。部分量表用总分来判断严重程度，部分用总均分和阳性项目数。论文里你不需要把所有量表都实现一遍，选两个有代表性的量表做深就够了：一个做维度分析（SCL-90），一个做严重程度判断（SDS），然后把全套计分逻辑写清楚。答辩时你可以说“系统的计分规则基于量表常模设定”，这句话一出来，档次立刻不一样。

5.3 测评报告如何生成：不只是数字堆砌

拿到总分和维度分数之后，怎么变成一份可读的测评报告？很多同学只是简单地显示“您的总分为52分”，连个解释都没有。在一个心理健康管理系统里，这样的报告没有任何专业价值。

专业的做法是这样的：预设一套报告解释规则，不同分数段对应不同的评价文本和建议方案。比如SDS抑郁自评量表，标准分53分以下为无抑郁，53到62为轻度抑郁，63到72为中度抑郁，72分以上为重度抑郁。系统根据测评结果自动匹配对应的解释文本，并生成建议（比如“建议预约心理咨询师进行面对面沟通”）。

报告生成模块的代码设计上，可以用策略模式来处理。定义一个ReportStrategy接口，每种量表类型实现一个策略类：

public interface ReportStrategy { ReportResult generateReport(AssessmentRecord record); }

再写一个工厂类，根据量表类型返回对应的策略实现。这种设计模式的引入，在论文里是非常明显的加分项，因为大部分毕设只做到了“能跑”，你做到了“有设计”。

6. 通用功能里的隐藏难点：统计报表、数据脱敏和文件上传

6.1 统计报表怎么让数据“讲故事”

系统有了测评数据之后，统计模块是展示你数据库查询功底的舞台。按学院统计测评人数、按时间统计测评趋势、按年级统计心理异常比例，这些查询都需要GROUP BY和条件聚合。拿“全校测评完成率趋势”举例，可以用一条SQL按月分组统计：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, COUNT(DISTINCT user_id) AS assessment_user_count FROM assessment_record WHERE deleted = 0 AND create_time >= #{startDate} GROUP BY DATE_FORMAT(create_time, '%Y-%m') ORDER BY month;

这种SQL在论文里非常出彩。但要提醒大家，统计报表不是画几个图表就完事了，要解释清楚这个统计对心理健康管理工作有什么决策价值。比如“发现某学院近期测评异常比例上升”，意味着需要重点干预。你能把数据背后的业务含义讲出来，老师在答辩时就不会觉得你的系统只是个花架子。

6.2 不要忽略的细节：密码强度、日志记录和并发控制

除了核心业务，还有几个细节容易被忽视，但确实能体现一个项目是否真正“有工程意识”。

第一个是操作日志。学生在系统里修改个人资料、提交测评、取消预约，这些关键操作都应该记录下来。可以简单地设计一张操作日志表，用Spring AOP做一个切面，标记需要记录日志的接口。实现并不复杂，但论文里写“系统提供了关键操作的完整审计日志”，会显得你的系统真正达到了“管理”级别。

第二个是预约模块的分布式锁或事务控制。预约功能除了数据库唯一索引，事务控制也必不可少。一个完整的预约流程要同时做两件事：插入预约记录、更新时段状态。这两步必须在一个事务里，要么都成功，要么都失败。用@Transactional注解可以轻松搞定，但面试和答辩都喜欢问这个，你要能说出事务的隔离级别和传播行为。

第三个是数据校验。后端接口接收参数时，一定用@Validated注解做参数校验。学生提交测评时后端要校验题目数量是否完整、是否所有题目都已作答，否则一份只答了一半的测评报告，算出来的分数毫无意义。

6.3 数据脱敏与隐私保护：心理健康系统必须跨过的门槛

心理健康管理系统和其他管理系统最大的不同，就是数据高度敏感。学生的测评答案、咨询记录，泄露出去可能对当事人的学业和生活造成严重影响。所以在论文设计和系统实现里，隐私保护这个环节一定要有，而且要写得扎实。

我的建议是至少做到三点：第一，密码使用BCrypt加密存储；第二，系统里展示学生列表时，手机号等敏感字段用****代替中间四位，这可以用一个简单的工具方法实现；第三，论文里可以写“测评答案字段采用加密存储，管理员仅能查看统计结果，无法查看具体作答明细”。这个设计不需要真的实现得很重，但能在答辩时展现出你对业务风险的深刻理解。

7. 论文结构怎么搭，答辩重点从哪几个方向准备

7.1 论文目录的黄金结构

这篇博文既然提到“毕业论文”，论文写作部分自然是重头戏。围绕这个题目，我建议论文目录按下面的结构来组织：

第一章 绪论。研究背景（为什么大学生心理健康需要信息化管理）、国内外研究现状（国外有较为成熟的校园心理服务平台，国内高校心理健康信息化建设方兴未艾）、研究目标和意义（设计并实现一个基于SpringBoot的大学生心理健康管理系统，提高心理服务效率）。

第二章 相关技术介绍。SpringBoot框架、MyBatis-Plus、MySQL、前端模板引擎（或Vue），每项技术写清楚版本、特点和选型理由。

第三章 系统分析。可行性分析（技术、经济、操作）、需求分析，要画出用例图和用例说明表。

第四章 系统设计。总体架构设计（B/S三层架构）、功能模块设计（把每个模块的功能列表写清楚）、数据库设计（ER图、数据字典、核心表结构说明）。这一章是论文的核心章节，建议写得越详细越好。

第五章 系统实现。按功能模块展示关键代码和实现界面截图。代码用核心片段即可，不要整段贴。截图注意不要泄露个人真实信息。

第六章 系统测试。功能测试用例表、测试结果、性能测试（可以用Postman简单测一下接口响应时间）。建议至少写20个测试用例，覆盖核心业务流程和边界场景。

第七章 总结与展望。总结系统成果，指出不足和改进方向。

这套目录结构已经经过很多次答辩验证，结构上挑不出大毛病。你需要做的，就是保证每一章内容都足够充实，尤其是第三、四、五章，千万别写成流水账。

7.2 答辩时的高频追问与应答思路

基于我带学生的经验，答辩老师对这类题目喜欢从以下几个角度追问：

第一个问题：系统如何保证测评数据的准确性？答：题目和计分规则采用可配置设计，反向计分题处理已覆盖，测评提交前后端双重校验，测评报告生成后写入独立表。

第二个问题：同校多个咨询师如何分配学生的预约请求？答：预约流程是先选咨询师再选时段，系统通过时段唯一索引防止冲突，咨询师有权确认或驳回请求，驳回时需填写理由。

第三个问题：你的系统相比市面上的心理测评APP有什么优势？答：系统对接的是校内心理咨询服务流程，不是单纯的测评工具，强调的是测评→报告→预约→干预的完整闭环，并考虑到了数据隐私和审计日志。（这里要提前复盘一下自己系统的闭环是否真的做通了，别被问穿。）

第四个问题：如果用户量增长到一万并发，系统会出什么问题？答：当前系统更适合校园级规模，若用户量激增，可引入Redis缓存热点数据、Nginx负载均衡、数据库读写分离等架构优化方案。（能说出方案名称，说明你确实思考过扩展性。）

这些都是很常见的高频问题，建议提前把答案写好、理解透，答辩时不要背稿子，用自己的话讲出来效果更好。

8. 部署与自测的实战心法：从JAR包到演示环境

8.1 本地开发环境配置清单

毕设答辩之前，开发环境的稳定性比什么都重要。我建议你按照这份清单把环境准备好，并提前在演示用的电脑上测试一遍打包流程：

• JDK 8或JDK 11（不要装太新的JDK，部分SpringBoot版本在高版本JDK上可能有兼容问题）
• Maven 3.6+（配置好阿里云镜像仓库，否则依赖下载慢到怀疑人生）
• MySQL 5.7或8.0，字符集选择utf8mb4
• IDEA社区版或旗舰版都可以，装上Lombok插件
• Redis（如果用JWT+黑名单方案的话，否则可以不装）

打包部署的命令非常简单，在项目根目录执行：

mvn clean package -DskipTests java -jar target/mental-health-system.jar

注意生产环境和本地环境的配置差异，application.yml里可以把数据库密码从环境变量中读取：

spring: datasource: url: jdbc:mysql://${DB_HOST:localhost}:3306/${DB_NAME:mental_health}?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: ${DB_USER:root} password: ${DB_PASSWORD:root}

这样你可以在启动时用--DB_PASSWORD=xxx指定密码，配置文件里不出现明文密码，答辩时也能多一个谈资。

8.2 自测时最容易忽略的五个场景

我发现很多学生自测时只测“主流程”，也就是登录、添加一条记录、删除一条记录，然后就说系统没问题了。真正到答辩演示时，老师随便一个操作就能让系统露出破绽。下面五个场景，建议你们在提交前认真自测：

第一个：学生提交测评时，如果有一道题漏选，系统能不能正确提示？前端有没有做必选校验，后端有没有做二次校验？这个场景我问过不少学生，能同时扛住前后端双重校验的不超过三成。

第二个：咨询师确认预约时，这个时间段已经被另一个学生预约了，系统是否会出现覆盖？测试方法是开两个浏览器窗口同时提交，或者用Postman并发请求。注意观察数据库里是否产生了两条冲突的预约记录。

第三个：管理员禁用某个学生账号后，这个学生是否还能通过旧Token继续访问接口？这是JWT方案的经典漏洞，如果你没有做Token黑名单，演示时被老师撞上了会很尴尬。

第四个：超长昵称、特殊字符（比如emoji）能不能正常保存和显示？数据库连接参数里没有配置characterEncoding=utf8的话，UTF-8特殊字符会直接变成问号，很影响观感。

第五个：删除一个已经被测评记录的量表，系统会不会报外键错误？如果你做了逻辑删除而没有做物理外键约束，这个操作可能是静默成功的，但会导致历史测评报告显示“量表已删除”，影响系统完整性。

这五个场景都是我踩过或看别人踩过的坑，提前测一遍，能帮你躲掉大部分翻车风险。

8.3 演示时让系统更亮眼的三个小细节

如果想让答辩演示效果更好，可以在系统里提前准备一套演示数据。用户角色各准备几个，测评记录和预约记录准备一定的历史数据，图表上要有曲线波动，不要把统计模块的数据做成一条直线。演示时可以从学生端入口进去，完整走一遍“登录→完成心理测评→查看报告→提交心理咨询预约→咨询师端确认预约→管理员端查看统计”全流程，这条路只要走通，整个系统就在老师心里立住了。

另外建议在演示前把数据库备份一个快照，万一演示过程中数据搞乱了，马上恢复重来。用Navicat或者mysqldump都行，这个细节虽然没有技术含量，但关键时刻能救你一命。

9. 关于SpringBoot和Java一些容易踩的坑，顺手帮你们排掉

写这个题目的读者基本都是Java和SpringBoot的初学者，这里我把开发过程中最常见的几个坑集中讲一下。学弟学妹们经常发消息问我：“为什么New Project的时候找不到SpringBoot 3.4.3选项？”——答案很简单，IDE内置的Spring Initializr有时候同步慢，或者你需要配置自定义的Initializr地址，像阿里云提供的https://start.aliyun.com就比默认的更快；另外一个更常见的原因是你本地JDK版本太低，SpringBoot 3.x要求JDK 17及以上，如果你还在用JDK 8，老老实实选SpringBoot 2.7.x。

还有经典的java: You aren't using a compiler supported by lombok, so lombok will not work，百分之八十的原因是你IDEA里装了Lombok插件但项目没有正确添加依赖，或者是编译时用了过旧的JDK。把pom.xml里的Lombok依赖版本升级到最新，并且让项目的JDK版本和IDEA设置里的Java编译器版本保持一致，问题基本就能解决。

另一个高频问题：VM option failed: Insufficient memory，通常是因为启动类配置了过大的JVM内存参数，而你的电脑物理内存不够。解决方法是把-Xmx调小，比如-Xmx512m，或者换成64位JDK。这类问题虽然不大，但如果发生在答辩当场，真的非常影响心态。

最后说一句实在话：做这种带管理性质的信息系统，最难写的不是代码，而是把业务想清楚、把设计说清楚。你在毕业论文里写下的每一个方案、每一张表结构，都应该能回答“为什么这样做”这个问题。你可以卷技术，但更多时候，工整的设计和清晰的思路，比多写几个花哨功能更能打动答辩组。希望这篇博文能帮到正在为这个题目头秃的你。

本文还有配套的精品资源，点击获取