1. 项目整体设计如何梳理高校心理健康系统的核心架构1.1 选题逻辑与需求还原动过毕设的人应该都有这种体会选题最怕的不是难而是“不好讲”。一个题目拿到手里功能是csdn上复制粘贴就能凑齐的那种答辩的时候导师问两句就露馅。我当时在这个基于Spring Boot的高校心理健康系统上花的功夫老实说超过了不少同学整年做的东西但效果也确实立得住——从开题到答辩整个过程基本顺畅因为每一块代码和每一张表我都能说出为什么这么做。先说需求还原。高校心理健康系统的核心场景不是社区论坛那种泛泛的“在线咨询”而是围绕一个真实组织高校内学生、咨询师、辅导员、管理员四个角色之间的业务流转。所以第一步不是急着写代码而是把线下业务流程捋清楚学生有心理健康诉求需要先做测评量表获得初步评估结果再根据结果选择预约咨询师咨询师有排班时间和专业方向咨询完成后需要记录结果辅导员需要关注重点关注学生管理员要维护基础数据、监控系统运行。我把这个流程拆成了五条主链路测评链路学生填写量表 → 系统自动评分 → 生成测评报告 → 系统根据结果给出建议预约链路学生查看咨询师排班 → 提交预约申请 → 咨询师确认/改期 → 咨询完成咨询记录链路咨询师填写咨询摘要 → 学生档案自动更新 → 心理状态标记变化关注名单链路系统根据测评结果和咨询记录自动生成需要重点关注的学生列表 → 辅导员可查看并介入管理链路角色权限管理、量表维护、院系数据统计、系统日志审计。这五条链路就是整个系统的骨架所有数据库表、接口、页面都是围绕它们展开的。这个设计思路特别适合答辩因为你可以很清楚地回答“你的系统解决了什么问题”而不是上来背概念。1.2 技术选型为什么是Spring Boot MyBatis Plus这个项目我用的是Spring Boot 2.x MyBatis Plus MySQL 5.7的组合前端用Thymeleaf加少量原生JavaScript管理端单独拆了一个页面目录。这套组合在高校毕设场景里几乎是“标准答案”但选它不是因为随大流而是有具体考量。Spring Boot的意义不用多讲自动配置和内置Tomcat能省掉大量环境搭建时间。相比早年的SSHStruts Spring Hibernate和SSMSpring SpringMVC MyBatisSpring Boot把配置文化压缩到了极致一个application.yml加几个注解就能起步这对毕设周期非常友好。MyBatis Plus则是个聪明选择。它不像JPA那样要求你对对象关系映射有深刻理解也不像原生MyBatis那样每个SQL都要手写。MyBatis Plus提供了基础的CRUD方法分页插件、逻辑删除、自动填充这些高频功能都是内置的真遇到复杂查询直接写自定义SQL就是。我项目里大部分单表操作都没写一条SQL但多表关联查询和统计报表还是手写的两边都兼顾。认证授权这块我用了Spring Security JWT的方案。为什么不用Shiro因为Spring Security和Spring Boot的整合更自然而且毕设答辩时“Spring Security的过滤器链”“JWT的无状态认证”这些点很容易展开讲。JWT尤其适合前后端分离以后的接口鉴权场景登录后拿到token后续请求带在请求头里后台不用存session会话状态天然分散对部署和扩展都友好。工具链上IDEA写代码、Navicat管理数据库、Postman测接口、Maven管理依赖、Git做版本管理。有同学问我为什么用Postman不用Swagger我都建议两个都装——Swagger能在浏览器里直接调试并生成接口文档对最后的文档撰写帮助很大但Postman在构造复杂请求和做批量测试时更快。两个工具各有优势就算到答辩前一天临时改字段也来得及同步调试。2. 核心模块拆解从用户端到管理端的完整闭环2.1 用户端功能细节学生端是这个系统的门面功能是否顺手直接决定演示效果。我实现的用户端功能可以分七块账号与资料注册登录、修改密码、完善个人信息包括学号、院系、专业、年级、性别等。这里的细节是学号绑定唯一的验证逻辑注册时校验学号是否在预置名单内防止无关人员注册。这个设计源自真实的校园业务需求——学生系统不对社会开放。心理测评这是整个系统的“心脏”也是最容易拔高技术含量的一块。我内置了三套常用量表每套量表包含若干道题目每道题目对应不同的计分规则提交后系统自动计算总分和维度分根据阈值自动生成测评结果良好/轻度/中度/重度并给出对应建议。详细逻辑后面单独说。预约记录学生查看所有咨询师的排班表选择可预约时段提交申请在咨询师确认之前可以取消。预约状态包括待确认、已确认、已完成、已取消、已过期五种。通知消息系统内嵌通知模块预约状态变更、测评结果生成、提醒消息都会推送到学生的个人消息中心。档案浏览由测评记录和咨询记录聚合而成的个人心理档案。这里注意学生只能看到自己的档案不可见他人信息。心理文章与自助资源我加了一个内容发布模块管理员和咨询师可以发布心理学相关文章和自助调适资源用于展示系统的完整体验。不是必须的功能但有了它系统的“高校心理服务”定位更完整。意见反馈学生可以匿名或实名提交反馈管理员在管理端处理。纯粹增加系统的人性化设计但也在评审时被导师提过“考虑得好”。用户端的功能清单有一个原则宁可少而精不要多而糙。毕业设计评审时最尴尬的不是功能太少而是功能哪个都有bug。所以我在用户端只保留了这些核心操作且保证每个操作都能顺畅跑通。2.2 管理端与咨询师端的差异化设计管理端和咨询师端虽然没有学生端那么多交互页面但从权限控制和业务流程角度看其实更需要精细处理。管理员端承担的角色是系统运营者。基础数据管理院系、专业、班级、用户管理账号启用/禁用/重置密码、咨询师排班审核、量表内容维护、文章发布审核、全部测评和预约记录查看、统计报表各院系测评覆盖人数、各量表结果分布都放在这里。管理端的典型特征是“看全局、能干预”所以表格筛选、导出、统计这些能力要比用户端强。咨询师端则是工作台模式。咨询师登录后看到自己的待确认预约、当日安排、历史咨询记录可以调整自己的排班时段咨询完成后填写咨询摘要并选择是否需要将该学生纳入重点关注名单。这里我特意做了一个小细节咨询师不能删除咨询记录只能新增或补充。因为从业务合规角度讲心理健康咨询记录必须可追溯、不可篡改这个点在答辩时是一个不错的加分项。角色权限我用的是标准RBAC模型用户表、角色表、菜单表、用户-角色关联表、角色-菜单关联表。可能有人觉得“只有三种角色的系统干嘛搞五张表”但真正的价值在于稳定性。以后系统加一个“院系心理协会成员”角色不用动代码结构只是在菜单分配时勾选一下就行。权限控制的粒度为按钮级别——不同角色看到同一个页面的不同操作按钮这在我的系统里是通过前端判断权限标识符实现的。2.3 数据库设计的关键表结构数据库设计是逢答辩必问的部分所以我这里花了不少心思也强烈建议把这一步当成核心讲清楚。整个库一共14张表我按业务域分成四组用户域sys_user用户主表、sys_role角色表、sys_menu菜单表、sys_user_role用户角色关联、sys_role_menu角色菜单关联。sys_user里面除了常规字段还有enable_flag是否启用、del_flag逻辑删除标记设计逻辑删除是因为心理档案必须保留留痕物理删除会造成不可恢复。测评域mental_dimension量表主表记录量表名称、类型、说明、mental_question题目表关联量表主键存储题目内容和选项、mental_result测评结果表存储学生每次测评的总分、维度分、等级、建议语。做量表的时候题目的选项并不是1对1固定分值而是采用维度映射每道题可以对应多个维度的权重最后按维度聚合计算这样量表判分更专业。预约域counselor_info咨询师扩展信息表包含咨询师介绍、专业领域、累计咨询次数、counselor_schedule排班表按日期和时段存储咨询师的空闲时间、appointment预约主表存放学生ID、咨询师ID、排班ID、预约时间、状态、备注。咨询域consultation_record咨询记录表存储咨询时间、咨询摘要、结论、是否纳入关注、attention_student重点关注学生表存储被标记的原因、当前等级、处理状态、notice_message站内消息表存储消息接收人、标题、内容和已读状态。我当时画ER图的时候刻意遵循了三件事主键统一采用雪花IDbigint每个表都有create_time和update_time自动填充字段每个外键关系都有索引。雪花ID在分布式环境下的应用价值在毕业设计阶段不是重点但养成好习惯是受益终身的。自动填充字段对应MyBatis Plus的MetaObjectHandler实现索引则直接用Navicat一键添加属于那种“谁都会、但不见得都做”的细节。3. 关键代码实现与踩坑记录3.1 心理测评模块的实现逻辑测评模块是这个项目里最值得详细讲的地方也是很多同学在拿到类似题目时最容易做浅的部分——比如直接一个表单提交后算个总分完了。但真实的心理测评量表不是这么工作的。以我内置的焦虑自评量表SAS为例它的计分规则是20道题目每道题4个选项正向题目按“没有或很少时间、小部分时间、相当多时间、绝大部分时间”分别计1/2/3/4分反向题目则反过来计4/3/2/1分最后把原始分乘以1.25取整数部分得到标准分再按标准分划分等级。如果不做权重设计只用一行SQL聚合是算不出来的。我当时的实现方式是mental_dimension表里存了量表的类型标识mental_question表里存了每个题目的direction字段0正向1反向和dimension_code维度标识。测评提交后后端接收入参为一个包含题目ID和所选选项的列表在Service层做逻辑计算public MentalResult calculateScore(Long studentId, Long dimensionId, ListAnswerItem answers) { // 1. 校验量表和题目 MentalDimension dimension mentalDimensionMapper.selectById(dimensionId); ListMentalQuestion questions mentalQuestionMapper .selectList(new LambdaQueryWrapperMentalQuestion() .eq(MentalQuestion::getDimensionId, dimensionId)); // 2. 按维度聚合计算 MapString, BigDecimal dimensionScoreMap new HashMap(); MapString, Integer dimensionQuestionCount new HashMap(); BigDecimal totalRawScore BigDecimal.ZERO; for (AnswerItem item : answers) { MentalQuestion q questions.stream() .filter(x - x.getId().equals(item.getQuestionId())) .findFirst().orElse(null); if (q null) { continue; } int rawScore item.getSelectedOption().getValue(); // 反向题反转计分 if (q.getDirection() 1) { rawScore 5 - rawScore; // 选项值1~4时反转 } totalRawScore totalRawScore.add(BigDecimal.valueOf(rawScore)); // 按维度累加 String dimCode q.getDimensionCode(); dimensionScoreMap.merge(dimCode, BigDecimal.valueOf(rawScore), BigDecimal::add); dimensionQuestionCount.merge(dimCode, 1, Integer::sum); } // 3. 标准分转换 BigDecimal standardScore totalRawScore.multiply(new BigDecimal(1.25)) .setScale(0, RoundingMode.HALF_UP); // 4. 等级判断 String level determineLevel(dimension.getType(), standardScore); String suggestion getSuggestionByLevel(dimension.getType(), level); // 5. 保存结果 MentalResult result new MentalResult(); result.setStudentId(studentId); result.setDimensionId(dimensionId); result.setTotalScore(standardScore); result.setLevel(level); result.setSuggestion(suggestion); result.setCreateTime(LocalDateTime.now()); mentalResultMapper.insert(result); // 6. 判断是否自动加入重点关注 if (SEVERE.equals(level) || MODERATE.equals(level)) { checkAndAddAttention(studentId); } return result; }这段代码从毕设答辩的角度看有三个亮点维度聚合、标准分转换、自动关注。那位问“你系统怎么自动识别心理问题学生的”的老师还没说完我就可以顺着代码讲清楚整套判断逻辑。实操的时候有两个容易踩的坑。第一个是反向题的处理很多同学把反转逻辑写错导致同样的问卷前后两次分数不一致。我当时专门写了测试类验证20道题里全部选“没有或很少时间”时分数是否等于理论最低值。第二个坑是并发重复提交学生双击提交按钮会出现两条测评结果记录后来的处理方式是在controller层加分布式锁其实单机场景下用synchronized也行以及在前端提交前禁用按钮。这种问题虽然不大但被老师测出来就很尴尬。3.2 预约与排班的状态机设计预约模块看起来是最普通的增删改查但实际上核心是一个状态机。我在appointment表里设计了五个状态PENDING待确认、CONFIRMED已确认、COMPLETED已完成、CANCELLED已取消、EXPIRED已过期。每一个状态之间的迁移不是随意发生的而是由不同角色在不同操作下触发的PENDING → CONFIRMED咨询师在学生提交预约后点击“同意”PENDING → CANCELLED学生或咨询师在确认前取消CONFIRMED → COMPLETED咨询师完成咨询后点击“结束咨询”填写摘要CONFIRMED → EXPIRED预约时间过后无人操作由定时任务批量扫描更新。我本来想用状态机框架如Spring StateMachine来做但后来想了想在这个场景里引入框架反而是过度设计。代码直接用一个Map或枚举的迁移合法性校验方法更直观答辩时也更容易解释。最终实现是一个枚举类定义好所有合法迁移public enum AppointmentStatus { PENDING, CONFIRMED, COMPLETED, CANCELLED, EXPIRED; private static final MapAppointmentStatus, ListAppointmentStatus TRANSITIONS new EnumMap(AppointmentStatus.class); static { TRANSITIONS.put(PENDING, Arrays.asList(CONFIRMED, CANCELLED, EXPIRED)); TRANSITIONS.put(CONFIRMED, Arrays.asList(COMPLETED, CANCELLED, EXPIRED)); } public boolean canTransitTo(AppointmentStatus target) { return TRANSITIONS.get(this) ! null TRANSITIONS.get(this).contains(target); } }排班表的时段时间槽也值得注意。我用的方案是counselor_schedule表直接存一条记录如2025-06-01 14:00-15:00一个时间段作为一个最小预约单元同一时刻只能被一名学生预约。查询时用SQL排除已经被预约的时间段就可以得到“可预约时段列表”。如果某一周咨询师临时有事可以直接把对应排班记录标记为停诊而不需要删除数据前后台都保留痕迹。这里踩过的一个实际问题是时区时间转换。当时排班页面显示的时间和入库时间差了8个小时排查了一阵才发现是前后端时间格式传递时Jackson的时区设置问题。解决方法是application.yml里统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这个属于那种“永远也查不出原因、一旦知道了永远都会记得”的坑。3.3 鉴权与过滤器链配置Spring Security JWT整合这块是踩坑重灾区很多同学做毕设时最怕的就是这里。我在项目里做了一套比较简洁的配置把逻辑讲清楚后其实不复杂。核心思想是JWT作为一个无状态票据生成于登录成功时包含用户ID、角色标识和过期时间用密钥签名之后每次请求通过过滤器解析它并把用户信息放进SecurityContext中。Spring Security的过滤链顺序是先走UsernamePasswordAuthenticationFilter登录再走我们自定义的JwtAuthenticationFilter校验票据最后到授权管理器。配置上最关键的几行代码是Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers(/api/auth/login, /api/auth/register, /swagger-ui/**).permitAll() .antMatchers(/api/student/**).hasRole(STUDENT) .antMatchers(/api/counselor/**).hasRole(COUNSELOR) .antMatchers(/api/admin/**).hasRole(ADMIN) .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class) .exceptionHandling().authenticationEntryPoint(restAuthenticationEntryPoint()); return http.build(); } }写这段代码时有几个细节容易被忽略。第一个是关闭csrf拦截。前后端分离用JWT后基本不需要csrf防护不关的话每次POST请求都会返回403。第二个是放行Swagger资源路径不然接口文档页面打不开影响评审。第三个是自定义AuthenticationEntryPoint当未登录用户访问受保护接口时返回JSON格式的401信息而不是默认的登录页重定向这样前端才能拦截并提示。第四个是密码加密我用了BCryptPasswordEncoder数据库里存的不是明文而是加盐哈希哪怕有人拿到数据库也无法逆向出密码。JwtAuthenticationFilter的实现核心是从请求的Authorization头中截取Bearer xxx的token调用JwtUtil解析如果解析成功且用户存在就手动构造UsernamePasswordAuthenticationToken并设置到上下文。这里有一个坑filter抛异常后不会自动走全局异常处理器必须自己try-catch包装后转发给AuthenticationEntryPoint。我当时在这个问题上卡了小半天后来干脆把filter里面所有解析逻辑包在一个大try-catch里处理后再重写response。还有一点关于注解权限。网关层配置好之后Controller层方法上还要加PreAuthorize(hasRole(ADMIN))之类的细粒度校验。一开始觉得很多余后来研究了一下发现这种“双层防护”在答辩时反而加分可以说“接口层面和控制层层面都有权限校验”。4. 远程调试、部署与配置避坑4.1 远程Debug调试配置按标题里的“远程调试”来理解这里包含两层意思一层是我们的项目支持你本地启动后自己调试另一层是如果项目部署在云服务器上团队成员或导师需要远程连上正在运行的JVM去查看运行时状态。远程调试在Spring Boot里是一个非常实用的配置。服务器上启动jar包时加上参数允许JDWPJava Debug Wire Protocol连接java -agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005 \ -jar university-mental-health-system.jar本地IDEA里设置一个Remote JVM Debug的Run ConfigurationHost填服务器IPPort填5005启动后就能像本地调试一样打断点。这个功能对排查部署环境特有的问题极其管用。我遇到过一个真实场景本地测试接口一切正常服务器上同样的接口却报NullPointerException后来远程调试跟在单步执行才发现是服务器上数据库里有一条create_time字段为NULL的脏数据导致接口在转换成VO时调用时间的格式化方法报错。如果只能靠打日志排查这类问题不知道要花多久。要注意的是远程调试会让JVM在断点处暂停生产环境绝不能开要么只在内网测试环境用要么用完后立刻关掉。实际上如果一个项目部署在云端且开放了5005端口有安全风险会导致任何人都能连接调试端口所以务必通过防火墙限制访问来源IP。4.2 部署到服务器两种方式实测这个系统的部署我有两套实测过的方式按需求复杂度选择。方式一简单直接单机部署前端静态资源由Spring Boot直接托管。Spring Boot的src/main/resources/static目录下放前端页面打包成单个jar后用nohup启动mvn clean package -DskipTests nohup java -jar target/mental-health-system.jar --spring.profiles.activeprod app.log 21 这条命令背后有三个知识点值得展开nohup让进程脱离终端的挂断信号--spring.profiles.activeprod指定生产环境配置数据库连接、日志级别等 app.log 21把标准输出和错误输出统一写入日志文件排障时全天日志都在。生产配置里MySQL连接串要显式加上useUnicodetruecharacterEncodingutf8和serverTimezoneAsia/Shanghai不然中文乱码和时区问题会花掉半小时。方式二前后端分离部署。把前端用Nginx托管Spring Boot只负责API。先把前端build后的dist目录上传到服务器/usr/share/nginx/html配置Nginx的location规则将/api/开头的请求代理到后端的8080端口location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }这样做的优势是可以更好地处理跨域、静态资源缓存、HTTPS证书而且页面和API的发布互不影响。对毕设而言方式一对目标是以最快速度上线演示的场景更友好至少少配置一个Nginx步骤。但如果你选择前后端分离从头就走这个架构那方式二反而更容易。4.3 配套文档和论文写作的同步要点标题里有“全套源码文档”这就是很多同学实习和工作后面临的真实场景。文档的价值不只是学校要求的材料它更像是让一个从未接触过你代码的人在三天内接手项目的桥梁。我建议不管是否毕业答辩都应该养成先写设计文档再写代码的习惯至少也应该同步更新。我们文档三件套就是开题报告、中期检查、毕业论文。开题报告重点写选题背景和意义中期检查写已完成工作和系统架构论文是整个系统的完整性描述。整个项目配套了常规的课题研究背景、需求分析、系统设计、系统实现、系统测试等内容。这些如果等到最后再来写会发现自己根本不记得三周前写过的某个接口到底为什么那么写。因此我索引的是代码里每个关键类都写了类注释标记需求编号和核心逻辑Git提交信息强制按功能命名如feat: 完成测评结果自动评分或fix: 修复反向题计分错误论文中的功能设计章节跟实际实现的菜单权限一一对应。这个“倒逼”思路的原则是文档不是写给别人看的是写给未来的自己的。答辩时老师如果问“这个接口都有哪些参数”而你半天答不上来印象分就掉了反之如果你能把文档、代码、演示三者对齐基本就是稳过的水平。5. 定制扩展与常见问题速查5.1 如何根据需求扩展系统毕业设计提交以后不是终点。实际上很多同学拿到项目以后不仅仅追求“能跑”还希望能重新设计和定制功能比如给自己的学校或学院的特定需求再加一层东西。这类定制需求我见过几种常见的方向扩展一增加新的量表。现在的系统内置了三套量表但如果某高校心理中心想换成自己的特色问卷或者想支持自定义量表不用改代码逻辑只需往库里的量表表和题目表插入新数据前端页面会自动读取。原因是量表数据的渲染完全由数据库驱动题目和选项通过接口动态加载不是写死在页面里的。这个设计在做毕设时可能没意识但在真实系统里非常关键。扩展二增加院系维度的数据分析。有同学想给辅导员一个可视化看板直观看到各院系的心理测评覆盖率、重点关注学生的分布。基于现有的统计接口只需增加按院系分组的时间范围查询SQL配合一个柱状图或饼图组件就能实现。数据层完全复用不需要动表结构。扩展三消息通知对接微信端。现在系统内置的站内消息表里存了所有已读状态。如果想让预约成功和测评完成时通过微信服务号模板消息通知学生只需要在发送消息的位置接入微信API调用。预约成功时调用微信推送接口异步发送模板消息学生不需要打开App就能收到通知使用体验提升明显。这个方向很多学生在大四下学期选做因为它连接了校园服务和主流社交软件在演示时容易让人眼前一亮。扩展四加入访谈记录的功能模块。心理测评毕竟是自填量表不能完全替代专业访谈许多高校希望系统记录线下访谈信息。要加这个功能需要新增一个访谈表包含学生ID、访谈时间、访谈人、访谈内容和干预意见。这个功能涉及的数据模型与现有的consultation_record非常接近可以做简单扩展。我不建议在设计阶段为了“定制”而加太多东西先做通可用于全流程的方案再根据改动成本选择扩展方向这才是更务实的路线。5.2 常见问题排查速查表把实际调试过程中遇到的高频问题整理成一个速查表对后来拿到这个项目的同学能省下大把时间。这里挑几个有代表性的问题现象可能原因解决方案接口返回401但登录接口正常JwtAuthenticationFilter里没正确取到Authorization头检查前端拦截器是否设置了token请求头字段名大小写是否一致前端页面中文乱码数据库连接串缺少characterEncodingUTF-8在连接串中显式指定useUnicodetruecharacterEncodingutf8预约时间显示差8小时Jackson时间序列化默认使用UTC时间段在application.yml中配置time-zoneGMT8并确保数据库连接的serverTimezone为Asia/Shanghai双击提交产生重复测评/预约记录缺少防重提交逻辑前端提交后立即禁用按钮后端对状态变更做条件更新update where statusPENDING数据库表数据删不掉逻辑删除字段del_flag默认把已删除记录隐藏不要用物理删除保留逻辑删除或在后台做“彻底删除”功能时自行拼接物理删除SQL部署到服务器后端口无法访问云服务器安全组未开放对应端口在安全组规则中添加8080或80端口同时确保本地防火墙没有拦截导出Excel时报内存溢出一次性加载全部数据到内存改用EasyExcel的分批查询方式每批查询1000条写入输出流总结一下排查的经验先看日志再看数据库最后才怀疑代码。Spring Boot的日志默认只打印INFO级别排查业务问题时可以临时把根日志调整到DEBUG看到SQL执行情况和参数绑定。但调回INFO前记住别忘否则生产环境日志量会非常吓人。另一个有价值的习惯是给表格都建好“操作前先查询”的依赖习惯。比如岗位更新时先在Service里查出旧数据再执行update如果查无记录直接抛出业务异常。这个步骤看似多一次查询但很多诡异bug都是被“直接按ID把所有字段覆盖更新”的做法坑出来的。6. 写在最后的一些真实心得做到最后一个独立模块的时候我最大的体会是毕业设计项目的含金量不在于用了多少技术栈而在于你是否能把自己做的东西讲清楚。拿这个心理健康系统来说我Spring Boot用得再熟答辩时如果只说“用MyBatis Plus做了增删改查”分数也上不去。但如果能讲明白“为什么测评分数要按维度聚合计算”“为什么预约状态用枚举迁移而不是if else判断”“为什么档案记录不允许删除”哪怕代码里一行事务注解都没加老师也能看出这是经过思考的。还有一个非常现实的问题这个项目里心理测评数据、咨询记录涉及学生隐私所以我在开发过程中特意在权限和日志层面做了约束。普通管理员的日志操作里学生测评的详细回答选项我做了脱敏只保留总分和等级dump日志时不会出现敏感内容。咨询记录只授权咨询师本人和系统管理员可见普通教师角色只能看到统计信息。这些设计在答辩时可以顺势提一句证明你考虑到了实际运营中最关键的数据合规问题。如果看文章的你刚好在用这个系统做毕业设计我的建议是把默认源码完整跑通后再动手改功能不要上来就大改数据库结构。先用默认管理员账号登录把所有菜单点一遍弄清楚每条业务流程对应的代码位置再找一个你最关心的模块比如测评或预约打断点逐步跟一遍最后再考虑定制扩展。这样做就算最后你只改了新增的一个量表和一个统计页面也会因为深入理解了系统而能在答辩时应对评委的各种问题。最后再分享一个小技巧项目上线前把数据库里所有外键检查一下顺便清理测试数据的CREATE_TIME给NULL的情况。这类细节很容易被忽略但在远程演示时可能突然让某个统计功能报错别问我怎么知道的。