1. 项目概述与核心需求拆解做高校信息化项目做了这么多年我发现心理健康管理这块一直是个“说起来重要、做起来边缘”的系统。很多学校要么用一套通用OA里的模块凑合要么干脆用Excel表格登记咨询记录导致数据散、统计难、预警滞后。这次接到“基于Spring Boot的高校学生心理健康管理系统”这个题目我其实是把它当成一个典型的校园业务中台来设计的而不只是写几个增删改查接口。先说清楚这套系统到底做什么。核心解决三件事学生心理测评的线上化组织与自动化计分、咨询预约与咨询记录的全流程管理、危机预警与数据统计分析的可视化呈现。角色上对应三类用户学生、咨询师通常也是辅导员或心理中心老师、系统管理员。学生端负责做测评、查报告、约咨询咨询师端负责处理预约、写咨询记录、查看所辖学生的测评结果管理员端负责量表维护、角色权限分配、院系班级数据同步、以及全局数据看板。说到为什么用Spring Boot而不是别的框架我多说一句。很多学校现有的信息化系统都是Java技术栈尤其是教务系统、学工系统基本都是Java系用Spring Boot做出来的服务可以很方便地和统一身份认证CAS/OAuth2对接也方便后续拆成微服务纳入学校的SOA总线。另外Spring Boot自带的starter机制、自动配置、内嵌Tomcat这些特性让整个项目的交付和运维门槛低很多学校里老师带着研究生也能维护。管理端用Vue Element Plus服务端用Spring Boot 2.7.x MyBatis-Plus MySQL 8.0这套组合在高校场景下非常成熟踩坑成本最低。适合谁来参考这篇内容如果你是正在做毕业设计的学生或者是在高校信息中心负责心理健康系统的开发运维人员甚至是心理中心的老师想了解系统该有哪些功能这篇文章都能给你一个相对完整的参考。重点不是贴一堆无脑CRUD代码而是讲清楚设计思路、表结构怎么建、测评分数怎么算、预约并发怎么处理、预警规则怎么定这些真正影响系统能不能落地的东西。2. 技术架构与方案选型思路2.1 后端框架选型为什么是Spring Boot MyBatis-Plus服务端用Spring Boot不用多说社区活跃、资料多、招人也容易。但我特别想聊一下为什么选MyBatis-Plus而不是Spring Data JPA或者MyBatis原生的XML方式。心理测评系统的数据模型相对稳定但查询非常灵活比如按院系、年级、性别、测评类型、时间段组合筛选学生测评完成率这种统计类SQL在JPA里写起来很别扭而MyBatis-Plus既保留了手写SQL的能力又提供了LambdaQueryWrapper这种链式查询语法开发效率比原生MyBatis高一大截。依赖版本上我强烈建议用一款相对保守的组合。我这次用的是Spring Boot 2.7.14 MyBatis-Plus 3.5.3 MySQL 8.0.33 Hutool 5.8.18。为什么不追Spring Boot 3.x因为Spring Boot 3基于Jakarta EE一些学校已有的基础组件比如旧版工作流引擎、旧版统一认证客户端可能存在兼容问题而且3.x要求JDK 17很多高校服务器上还是JDK 82.7.x JDK 8这个组合兼容性最稳。热词里有人问“Spring Boot 2.3.x和2.6.x有什么区别”这种版本纠结在我看来意义不大只要不是用太老的2.1.x核心功能差异不明显重点看JDK版本和依赖兼容。前端我选了Vue 2 Element UI没上Vue 3 Element Plus。理由很实在一是校内二次开发的主力可能是刚接触前端不久的研究生或老师Vue 2的教程最多遇到问题最容易搜到答案二是很多学校已有的前端工程就是Vue 2保持一致便于统一维护。如果你是新项目且团队有前端基础直接上Vue 3 Vite也没问题思路完全一样。2.2 权限模型基于RBAC的三端隔离心理健康系统有个特殊性——数据极其敏感。学生的测评结果、咨询记录属于隐私数据不能像普通学工系统那样随便查。所以权限模型上我用了经典的RBAC基于角色的访问控制并且做了两层控制菜单权限用角色控制数据权限用部门/院系控制。具体角色设计如下角色核心权限数据范围学生测评、查看本人报告、预约咨询仅本人数据院系咨询师查看本院系学生测评数据、处理预约、写记录本院系心理中心管理员量表维护、全校数据统计、账号管理全部系统管理员系统配置、角色权限、数据字典全部这里特别注意一点学生虽然能查看测评报告但原始题目的作答明细建议只保留近三次历史作答明细要默认隐藏只展示趋势曲线。从心理专业角度看来访者反复回看早年详细作答内容可能引发不必要的心理负担这个设计也符合心理咨询的伦理要求。数据权限的拦截我是通过MyBatis-Plus的DataPermissionInterceptor实现的在查询语句中自动拼接dept_id或college_id条件保证咨询师传一个studentId越权查别院系学生的数据时SQL层面就直接查不出来而不是靠业务代码判断。这种在持久层做数据隔离的方式比较可靠不容易漏。2.3 数据库核心表设计数据库设计是这类系统最关键的部分表结构设计不合理后期统计和扩展都是灾难。我整理了核心表如下sys_user用户表字段包括id, username, password, real_name, role_type, college_id, grade, major, phone, status。学生信息从学工系统同步做好student_no唯一索引。sys_role / sys_user_role角色表与用户角色关联表。college_info院系列表包含college_id, college_name, parent_id支持二级院系树结构。mental_scale量表信息表字段有scale_id, scale_code, scale_name, scale_type(SCL-90/抑郁自评/焦虑自评等), question_count, dimension_config(JSON), status。mental_question题目表question_id, scale_id, question_no, question_content, option_config(JSON), sort_order。mental_assessment_record测评记录主表record_id, user_id, scale_id, assessment_status(进行中/已完成), start_time, submit_time, total_score, result_level, detail_json(各维度分数), risk_level。mental_assessment_answer作答明细表answer_id, record_id, question_id, option_value, score。counseling_slot咨询时段表slot_id, consultant_id, slot_date, start_time, end_time, max_count, booked_count, status。counseling_appointment预约记录表appointment_id, user_id, slot_id, consultant_id, status(待确认/已确认/已完成/已取消), appointment_type, remark, cancel_reason。counseling_record咨询记录表record_id, appointment_id, user_id, consultant_id, issue_type, content_summary, suggestion, next_follow_up_date, create_time。risk_alert_record危机预警记录表alert_id, user_id, alert_type, risk_level, trigger_rule, description, status(待跟进/跟进中/已闭环), handler_id, handle_time, handle_result。sys_operation_log操作日志表由AOP切面统一写入。这里有个设计要点测评明细和汇总分表存储。查询列表页只需要总分的汇总数据会把detail_json这种大字段放到主表会让列表查询变慢把明细单独放一张表需要时再关联查性能好很多。JSON字段在MySQL 8.0里可以直接用json类型MyBatis-Plus支持JacksonTypeHandler做自动映射很方便。3. 核心功能模块设计与实现要点3.1 心理测评模块多量表可配置架构心理测评是这个系统的灵魂模块不能做成“写死几个量表”因为心理中心老师经常会引入新的问卷或修订已有量表。所以我把量表设计成了配置驱动的结构量表基础信息、维度配置、题目、计分规则都做成可配置。维度配置是一个核心设计。SCL-90量表为例它包含9个因子维度躯体化、强迫症状、人际关系敏感、抑郁、焦虑、敌对、恐怖、偏执、精神病性外加“其他”维度共10个因子。dimension_config字段的JSON结构我按照这样设计[ { dimensionCode: somatization, dimensionName: 躯体化, questionNos: [1, 4, 12, 27, 40, 48, 49, 52, 53, 56, 58], weight: 1 }, { dimensionCode: depression, dimensionName: 抑郁, questionNos: [5, 14, 15, 20, 22, 26, 29, 30, 31, 32, 54, 71, 79], weight: 1 } ]有了维度配置计分逻辑就完全通用了不需要为每个量表单独写一套计算代码。每次测评提交后后端遍历当前量表的维度配置把questionNos对应的题目得分汇总得到该维度的原始分。SCL-90的评分标准里每个题目按1~5分计没有症状~严重因子得分 该因子所有题目得分之和 / 该因子题目数。判断标准是因子得分≥2则为阳性≥3则为中度及以上所有因子得分均小于2为阴性总分超过160或阳性项目数超过43则需要关注。这里我加了一个很关键的设计——测评防作弊与有效性校验。很多学生做心理测评会胡乱作答如果系统不管统计结果完全失真。我的做法是加入测谎题逻辑配置量表时可以指定若干个“测谎题对”例如“我感到孤独”和“我觉得别人都很友善”如果一对方向相反的题目得分差值过大就判定为无效问卷。另外对提交耗时也做了约束正常完成90题SCL-90至少需要3~5分钟如果1分钟内全选同一选项提交系统会弹窗提示并允许重新作答一次但仍然记录原始提交数据不直接销毁方便心理中心追溯。作答过程的自动保存也是必须做的。学生做到一半可能关掉浏览器或断网所以每个题目作答后通过防抖方式自动保存到临时表重新进来时读取进度并续答。这个功能对实际体验提升非常明显否则学生做了一半找不到进度下次又要从头开始流失率会很高。3.2 咨询预约模块时段制设计与并发处理咨询预约不能做得像普通讲座报名那么简单因为心理咨询是一对一服务咨询师的时间段非常有限而且预约后经常有人放鸽子。我采用的是时段预约制咨询师在后台按周配置可预约时段比如周一上午9:00-9:50每个时段只放1个名额个体咨询。数据库层面用counseling_slot表维护时段用booked_count字段记录已预约人数。关键问题是并发预约冲突处理两个学生同时点同一个时段的最后1个名额如果只用select判断再update会出现超卖。解决方法是分布式锁 数据库乐观锁双保险。项目初期没有引入Redis避免增加运维复杂度所以我用数据库乐观锁实现SQL如下UPDATE counseling_slot SET booked_count booked_count 1 WHERE slot_id #{slotId} AND booked_count max_countMyBatis-Plus的UpdateWrapper里带上booked_count max_count条件如果影响行数为0说明时段已满或冲突直接返回“该时段已被预约”这种方案在单机应用下完全够用。但如果学校后续要做多实例部署建议还是引入Redis的setNx做分布式锁这个我在后续扩展里会讲到。预约状态机的设计也很重要。状态流转是待确认 → 已确认 → 已完成或者待确认 → 已取消已确认 → 已取消。学生提交预约后默认是待确认状态咨询师在后台确认后变成已确认届时候系统自动锁定时段不可再取消如需取消必须联系咨询师手动操作。咨询完成后咨询师在系统中填写咨询记录状态变为已完成。我在状态变更时都记录了操作人、操作时间和原因便于后续追溯。3.3 危机预警模块规则引擎与闭环跟进心理健康系统的真正价值在“预警”而不是“记录”。如果只是把测评结果存储下来那就成了一个电子档案库失去了主动干预的意义。所以我在系统里单独设计了一个危机预警模块核心是两部分预警触发规则和跟进闭环流程。预警触发规则我用的是可配置的规则引擎规则写在数据库表里而不是写死在代码中。这样心理中心老师可以根据本校实际情况调整阈值而不用改代码。例如规则编码规则名称触发条件RULE_001测评总分高危总分 ≥ 200RULE_002抑郁因子高危抑郁因子得分 ≥ 3RULE_003自杀相关条目阳性第15题“想结束自己的生命”得分 ≥ 2RULE_004近期测评大幅恶化比上次测评总分升高超过 40 分RULE_005多次未完成咨询主动预约连续2次未到场规则引擎的执行逻辑不复杂测评提交后遍历所有启用的规则命中则生成一条risk_alert_record同时自动给心理咨询中心管理员和对应院系咨询师推送通知站内消息 短信接口预留。需要注意的关键点是预警必须形成闭环。每条预警记录有一个状态机待跟进 → 跟进中 → 已闭环。咨询师看到预警后必须在系统里填写干预记录包括是否约谈、约谈结果、后续计划、下次跟进日期。超过设置时限仍未闭环的预警系统每日定时任务会再次提醒防止预警被遗忘。这里有个涉及心理伦理的问题系统只能起到辅助作用预警不能替代人工干预。学生测评结果达到高危线时系统应该建议咨询师尽快联系学生而不是直接给学生本人推送“你有严重心理问题”之类的生硬通知这会造成二次伤害。所以系统的通知逻辑是只推送给管理端和咨询师端学生端的报告页只做温和的提示语比如“最近你可能有些情绪困扰建议前往心理中心与咨询师聊聊”不带任何诊断性结论。3.4 数据统计看板多维度交叉分析管理端的数据看板是心理中心老师最常用的功能做好了这个模块系统的“行政价值”就体现出来了。我用ECharts做可视化展示几个核心指标全校测评完成率按院系、年级下拉筛选。各量表各风险等级人数占比正常/轻度/中度/重度。近12个月测评趋势折线图。各因子阳性率排名比如全校学生SCL-90中抑郁维度阳性率最高说明需要针对性干预。咨询预约完成率与爽约率按咨询师排名。写统计SQL时最容易踩的坑是测评完成率的计算口径。我遇到过一种情况某院系有800人但系统里的在校生数据只有750人如果直接用已测评人数/系统在册人数算完成率不同步数据的话会失真。这里的处理方式是把完成人数和应测人数分别从两张表查出来分子是mental_assessment_record里已提交的记录去重人数分母是sys_user当前在校状态的学生数。还需要注意学年学期维度所以统计SQL里应带上学期字段或时间范围条件。指标的另一个坑是**“多量表混合统计”**。如果学校同时使用SCL-90、SDS抑郁自评量表、SAS焦虑自评量表不能把所有测评记录混在一起算风险占比因为不同量表的评分标准和风险分层不同。我的做法是在看板最上层加一个“量表类型”筛选器默认按当前考核周期使用的主要量表展示其他量表另开标签页展示。4. 关键实现细节与实操过程4.1 技术栈清单与项目初始化项目本身我用的是标准的Maven多模块结构分成common公共工具、system用户权限、assessment测评、counseling咨询预约、statistics统计、admin管理端入口几个模块。这样划分的好处是职责清楚后续如果要拆微服务每个模块天然就是一个候选服务。初始化的关键依赖如下parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.14/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.18/version /dependency /dependencies有人问“IntelliJ IDEA社区版怎么用Spring Boot”我现在顺便说一句。IDEA社区版确实不带Spring Initializr但你可以直接在start.spring.io网站上把基础工程下载下来再用IDEA以Maven项目方式导入开发和调试完全没问题。社区版缺失的Spring相关插件主要影响配置文件提示不影响功能开发学生党做毕业设计完全够用。4.2 测评接口的设计与实现测评模块的核心接口有四个获取量表详情、提交测评、获取测评报告、获取历史测评列表。我重点说提交测评这个接口它涉及一个分布式事务的边界问题。正常流程是这样的学生提交90道题的作答结果 → 系统逐题插入作答明细表 → 计算各维度得分与总分 → 更新测评记录主表 → 触发风险预警规则 → 可能写入预警记录。如果这些操作放在一个事务里数据一致性有保证但同时也会带来一个性能问题如果作答明细有500道题有些量表题目多逐条插入会明显变慢。我的优化方案是使用MyBatis-Plus的批量插入能力把明细按200条一批分批写入再用Transactional包裹整个提交逻辑。另一个与测评提交相关的关键点是幂等性设计。前端网络抖动用户点击“提交”按钮后发现没反应再点一次就可能出现重复提交。我在测评记录表上加了user_id scale_code submit_time的联合唯一索引但更稳妥的方式是在前端生成一个requestIdUUID后端在Redis缓存里判断该requestId是否已处理。没引入Redis的情况下也可以用数据库唯一索引但测评场景中用户可能隔几天再做一次同一量表时间戳维度需要精确到秒甚至毫秒判断逻辑容易出错。最终我是这样实现的在mental_assessment_record表增加submit_token字段学生在获取测评详情时后端生成一个预提交的record_id提交接口带上这个id如果该记录已经是完成状态直接返回“该测评已提交”从源头避免了重复。测评报告的生成我觉得要重视可读性。系统不能让心理中心老师或者学生看到一堆因子分数就完事报告里应该带解释文本。我在量表配置表里增加了一个report_template字段用模板引擎我用的是Freemarker生成带解释文本的HTML报告。模板内容由心理老师审核后固化比如当SCL-90强迫症状因子得分在2~3分之间时模板输出“你在强迫症状维度显示轻度倾向常见表现包括不必要的想法反复出现、难以摆脱这不代表你有心理问题但建议关注一下自己的压力水平。”这种措辞需要心理专业老师把关技术侧只负责模板渲染。4.3 AOP操作日志统一埋点不侵入业务高校管理系统有个特点管理员操作涉及学生隐私数据每次查询和修改都要能追溯到人。我一开始试着在每个Controller手动写日志但写了十几个接口就发现根本维护不下去。后来改成AOP统一注解的方式才把这个问题彻底解决。具体做法是自定义一个OperationLog注解标注在Controller方法上使用AspectJ切面拦截。切面逻辑里解析当前用户的token获取操作人信息然后根据注解参数记录操作类型和操作模块。核心代码长这样Aspect Component public class OperationLogAspect { Around(annotation(operationLog)) public Object around(ProceedingJoinPoint joinPoint, OperationLog operationLog) throws Throwable { long startTime System.currentTimeMillis(); Object result; try { result joinPoint.proceed(); saveLog(joinPoint, operationLog, null, System.currentTimeMillis() - startTime); } catch (Exception e) { saveLog(joinPoint, operationLog, e.getMessage(), System.currentTimeMillis() - startTime); throw e; } return result; } }日志内容除了基础的操作人、操作时间、操作模块、操作类型外我还会记录方法参数中关联的业务主键比如userId或appointmentId方便后续定位“谁在什么时间改了什么数据”。这个功能对心理中心处理投诉纠纷时非常有用有一次某个学生的测评结果疑似的泄露就是靠操作日志定位到是一位院系辅导员越权导出了数据。注意AOP切面不要切Controller里所有方法那样日志量太大且很多无意义我建议只给涉及敏感操作的接口加上注解比如导出测评报告、修改用户角色、删除咨询记录、调整预警状态等。4.4 敏感数据安全实践心理健康系统的数据安全级别比普通业务系统高得多这是很多人容易忽视的。测评记录和咨询记录属于健康医疗类隐私数据需要额外保护。我做了以下几件事第一数据库层面加密存储。学生的姓名、手机号属于个人敏感信息用AES算法加密后存储。查询时通过自定义的MyBatis-Plus类型处理器自动解密。对于不需要明文展示的字段比如测评明细的作答内容不加密但数据库账号最小化授权读写账号分离。第二传输层防护。全站启用HTTPS接口层通过拦截器校验Token有效性。Token用JWT实现过期时间设为2小时每次请求刷新。这里有个细节JWT secret不能写在配置文件里明文存储我放在环境变量中加载防止代码仓库泄露后token被伪造。第三导出文件防护。系统支持测评报告导出PDF用于存档但导出的PDF要打上当前操作人的数字水印工号时间这样即使PDF被拍照外传也能追溯到来源。这个功能实现不复杂用Apache PDFBox往页脚写一行半透明小字即可。第四前端按钮权限控制。光有后端权限不够前端也要根据角色动态渲染菜单和按钮避免咨询师看到管理员的“全部数据导出”按钮。后端接口仍然做权限校验前端权限只是提升体验不做安全边界。5. 常见问题与排查技巧实录做完这套系统我整理了几个别人最容易踩、我自己也真实踩过的问题写成速查表分享出来问题现象原因分析解决方案测评提交后偶发500错误明细表批量插入时超过MySQLmax_allowed_packet限制将批量插入改为200条一批或者调大max_allowed_packet参数咨询师看不到部分学生测评结果数据权限SQL拼接了多个院系条件时出现OR和AND优先级错误使用MyBatis-Plus的DataPermissionInterceptor配置自定义SQL片段并在测试环境用不同角色账号验证预约时段出现超卖查询和更新之间没有事务与锁保护使用UPDATE ... WHERE booked_count max_count原子更新影响行数为0时返回失败总分计算结果与Excel手工核对不一致维度配置里questionNos漏了题或者权重配置错误增加“量表配置校验”功能保存量表配置时自动判断题目编号是否连续、是否重复、维度题目是否互相覆盖预警记录重复生成同一测评记录被重复提交触发多次规则引擎预警生成前检查该record_id是否已有同规则的记录否则插入服务器重启后定时任务不执行单机定时任务默认只在一个实例上运行多实例部署时重复触发引入ShedLock框架或改用XXL-Job以数据库锁保证同一任务只有一个实例执行再单独说一下那个并发预约的排查过程。上线第一周就收到学生投诉说两个人都收到了“预约成功”的短信但咨询师只确认了一个。查日志发现两个请求几乎同时进入都执行了select booked_count此时都读到0然后都执行了update第二个update覆盖了第一个。这个案例很典型问题不在数据库事务而在并发控制策略。后来改成原子update才解决。如果你所在学校后续做了微服务拆分还需要在原子update的基础上再加一层Redis分布式锁形成双保险。测评分数计算错误的问题我也要说一下。有次心理中心老师反馈某个学生的SCL-90总分和手工计算差了3分查了半天发现是维度配置里“其他”维度第19、44、59、60、64、66、68题没有正确映射到总分的计算逻辑里。SCL-90的总分是所有90个题目的得分总和而我在实现里一开始把总分算成了10个因子得分的加权和各因子乘以题目数再求和理论上应该等于90题之和但维度配置漏了题目的话就对不上。这就是配置驱动架构的常见风险配置错了代码没问题但结果错了。所以我加了配置校验和大批量随机抽检逻辑每次量表配置有变更时自动用最近100条有效作答记录重新计算一遍总分和原有总分对比偏差超过0.5分就报警提示。前端排查方面有一个表格分页的坑值得提醒Element UI的el-table配合自定义分页组件切换页码后数据正常但导出按钮导出的是当前页数据而不是全部筛选数据。原因是导出接口只接收了pageNum和pageSize没有把筛选条件传给后端。修改方式是把筛选条件院系、年级、量表类型、时间范围全部作为导出参数提交。这个场景在心理中心老师导出全院测评完成率时经常遇到导出数据不全最容易引发信任危机一定注意。性能层面当全校学生超过2万人且每个人有多次测评记录时列表页查询会明显变慢。我做了两层优化第一是在mental_assessment_record表上给(user_id, scale_code, submit_time)建联合索引第二是统计分析接口借助MySQL的GROUP BY配合ROLLUP做预聚合避免每次看板加载都全表扫描。如果数据量继续增长到10万建议把统计功能改为离线任务预计算用定时任务把每日汇总结果缓存到一张统计表前端查询直接读统计表。还有一个容易被忽视的点——表字段字符集。我遇到过数据库里中文乱码排查了一圈发现是建表语句里没有指定utf8mb4字符集默认用了latin1。现在的规范是MySQL 8.0建库时统一使用utf8mb4_unicode_ci提供全量SQL脚本时也要检查好避免因为字符集不一致导致姓名里的生僻字保存报错。心理测评系统的学生名单从学工系统同步时如果学生姓名中有生僻字这个问题的杀伤力会立刻体现。最后我想聊聊部署。这套系统的部署不建议搞得太复杂用Docker Compose编排两个容器就够一个MySQL 8.0一个应用服务。前端打包成静态文件用Nginx容器承载并配置HTTPS证书。放一个我实际使用的docker-compose.yml片段供参考services: mysql: image: mysql:8.0 container_name: mental-mysql environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: mental_health volumes: - ./mysql/data:/var/lib/mysql - ./mysql/init:/docker-entrypoint-initdb.d ports: - 3306:3306 command: --character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci app: build: ./backend container_name: mental-app depends_on: - mysql environment: SPRING_PROFILES_ACTIVE: prod DB_HOST: mysql DB_PORT: 3306 ports: - 8080:8080注意SPRING_PROFILES_ACTIVE不要用默认的default环境生产环境的数据库连接、日志级别、文件上传路径等都要走独立配置避免本地调试配置泄漏到线上。6. 写在最后的一点体会做完这套心理健康管理系统我最大的感受是这类系统的技术难度其实不高难的是把心理专业的需求翻译成技术人员能实现的逻辑。比如测谎题的判定阈值、预警触发规则的粒度、报告解释文本的措辞这些都不是程序员拍脑袋定的需要和心理中心老师反复沟通确认。我在系统上线前的需求评审会上专门邀请了心理咨询中心的老师一起过了一遍量表配置和预警规则果然发现了几个我原以为对的逻辑问题。另外如果你准备照着这个思路做毕业设计我建议别一上来就写代码先把表结构设计清楚尤其是量表配置、预约状态机、预警闭环这三个核心流程的时序图和数据流图画明白。这些前置工作占整个项目40%的精力但能帮你少改一半代码。最后分享一个小技巧开发阶段可以把mental_assessment_answer表的批量写入逻辑单独做成一个压力测试用例模拟1000个学生同时提交测评的并发场景。我在上线前做过一次压测发现Tomcat默认的max-threads是200高峰期测评提交会出现排队。后来把Spring Boot内嵌Tomcat的server.tomcat.threads.max调整到400并开启accept-count缓存连接峰值响应时间从原来的3秒左右降到了1秒内。这个调整虽然简单但对全校统一组织测评时的体验提升非常明显。这套系统后续还能继续扩展的方向也不少比如对接企业微信或钉钉的消息通知、引入自然语言处理做咨询记录的自动摘要、基于历史测评数据做学生心理状态的预测模型这些都是更长期的事情了。当前阶段把测评、预约、预警三条主链路跑稳就已经能帮心理中心的老师们省下大量重复统计的精力了。
