大学生心理健康系统实战：Spring Boot+MyBatis量表计分与预警设计

简介这是一套面向高校学生、Java初学者及课程设计开发者的大学生心理健康系统完整项目源码基于SSMSpring、SpringMVC、MyBatis框架搭建涵盖在线咨询、心理测试、预约管理、数据分析与报告生成等核心模块适合用作毕业设计、课程大作业或Java Web实战练手。压缩包共860个文件约17.7MB其中143个java文件承载后端业务逻辑156个js与52个vue、52个html、46个css文件构成前端交互界面另有svg、gif、jpg、png等图形资源及xml、sql、properties等配置与数据库脚本结构完整、层次清晰。目前已有284人学习下载。项目采用前后端分离思路集成JWT身份验证与Spring Security安全机制附带数据库建表脚本与运行批处理文件读者可据此快速理解SSM整合流程、掌握心理量表算法实现与数据可视化报告的开发方法并在此基础上扩展情绪日记、互助社区等功能。1. 大学生心理健康系统从一份课程设计到能扛住真实流量的落地拆解每年毕业季计算机专业的群里总有人问“大学生心理健康系统.zip 这个题目怎么做”。表面看它是个普通的 Java Web 课程设计实际动手才发现坑不少心理量表怎么存、测评结果怎么算、预警逻辑怎么设计、隐私数据怎么脱敏每一个都不是 CRUD 能糊弄过去的。我前后帮人调过三版这类系统从 Servlet 裸写到 Spring Boot 前后端分离都趟过一遍。这篇笔记就按“能跑起来、能演示、能讲清楚”的标准把大学生心理健康系统的技术选型、数据库设计、核心测评算法和部署排错完整拆一遍。适合正在做课程设计、毕设或者想把它改造成真实校园工具的人。2. 技术选型与数据库设计别一上来就堆微服务2.1 为什么 Spring Boot MyBatis 是这类系统的最优解大学生心理健康系统的业务复杂度其实不高核心就是用户管理、量表管理、测评记录、预警规则四块。我见过有人上来就 Spring Cloud 拆五六个服务结果答辩时连注册中心都讲不明白。常见做法是单体 Spring Boot 打天下理由很实在部署简单、调试直观、课程设计周期内能做完。技术栈我一般推荐这套组合层次选型理由后端框架Spring Boot 2.7.x生态成熟资料多答辩好讲持久层MyBatis-Plus单表 CRUD 不用写 XML复杂查询再手写数据库MySQL 8.0窗口函数、JSON 字段都能用前端Vue 3 Element Plus组件全表格表单开箱即用缓存Redis可选量表题目缓存减少重复查询鉴权JWT Spring Security无状态前后端分离友好如果你的环境只能用 JDK 8Spring Boot 降到 2.3.x 也能跑但 MyBatis-Plus 版本要对应降到 3.4.x否则启动会报NoSuchMethodError。这个坑我踩过版本对齐表一定要查官方文档。2.2 核心表结构五张表撑起整个系统数据库设计是这类系统的命门。心理量表题目、选项、计分规则如果设计成一张大表后期加量表会痛不欲生。我一般拆成五张核心表-- 用户表学生和咨询师共用用 role 区分 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) UNIQUE NOT NULL COMMENT 学号/工号, password VARCHAR(100) NOT NULL COMMENT BCrypt加密, real_name VARCHAR(50), role TINYINT DEFAULT 0 COMMENT 0学生 1咨询师 2管理员, college VARCHAR(50) COMMENT 学院用于分层统计, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 量表表一个量表一条记录 CREATE TABLE scale ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scale_name VARCHAR(100) NOT NULL COMMENT 如SCL-90、SDS, description VARCHAR(500), question_count INT COMMENT 题目总数, scoring_rule JSON COMMENT 计分规则见下文, status TINYINT DEFAULT 1 COMMENT 1启用 0停用 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 题目表选项用JSON存避免选项表关联查询 CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scale_id BIGINT NOT NULL, content VARCHAR(500) NOT NULL, options JSON NOT NULL COMMENT [{label:没有,score:1},...], sort_order INT DEFAULT 0, INDEX idx_scale (scale_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 测评记录表一次测评一条答案存JSON CREATE TABLE assessment_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, scale_id BIGINT NOT NULL, answers JSON NOT NULL COMMENT {1:2,2:3} 题号:选项分, total_score INT, result_level VARCHAR(20) COMMENT 正常/轻度/中度/重度, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_time (user_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 预警表触发规则后写入咨询师跟进 CREATE TABLE warning ( id BIGINT PRIMARY KEY AUTO_INCREMENT, record_id BIGINT NOT NULL, user_id BIGINT NOT NULL, level TINYINT COMMENT 1关注 2预警 3危机, handled TINYINT DEFAULT 0, handler_id BIGINT, remark VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有几个设计决策值得说清楚。第一选项用 JSON 而不是单独建表是因为选项永远跟着题目走没有独立查询需求JSON 省一次 JOIN。第二答案存 JSON 而不是一行一题是因为一次测评几十道题存 JSON 读取时一次拿全计算分数在内存里做比 SQL 聚合快得多。第三scoring_rule用 JSON 存是为了支持不同量表的差异化计分——SCL-90 是因子分SDS 是粗分转标准分规则不一样硬编码会写死。2.3 量表计分规则怎么配scoring_rule的 JSON 结构我一般这样设计{ type: sum, dimensions: [ {name: 躯体化, questions: [1,4,12,27,40,42,48,49,52,53,56,58]}, {name: 强迫症状, questions: [3,9,10,28,38,45,46,51,55,65]} ], levelRules: [ {max: 160, level: 正常}, {max: 200, level: 轻度}, {max: 250, level: 中度}, {max: 9999, level: 重度} ] }type支持sum总分、average均分、standard标准分转换。dimensions用于因子分统计levelRules按分数区间映射等级。这样加新量表只需要插数据不用改代码。我见过有人把 SCL-90 的因子分写死在 Service 里后来要加 SDS 量表直接重写血泪经验。3. 测评流程与预警逻辑从提交答案到触发预警的完整链路3.1 测评提交接口的完整实现测评流程是这类系统最核心的链路学生提交答案 → 后端计分 → 判定等级 → 触发预警 → 返回结果。我用一个 Service 方法把它串起来Service public class AssessmentService { Autowired private ScaleMapper scaleMapper; Autowired private QuestionMapper questionMapper; Autowired private AssessmentRecordMapper recordMapper; Autowired private WarningMapper warningMapper; Transactional(rollbackFor Exception.class) public AssessmentResult submit(Long userId, Long scaleId, MapInteger, Integer answers) { // 1. 校验答案完整性防止前端漏传 Scale scale scaleMapper.selectById(scaleId); if (scale null || scale.getStatus() 0) { throw new BizException(量表不存在或已停用); } ListQuestion questions questionMapper.selectByScaleId(scaleId); if (answers.size() ! questions.size()) { throw new BizException(答案数量不匹配期望 questions.size() 题); } // 2. 计算总分 int totalScore answers.values().stream().mapToInt(Integer::intValue).sum(); // 3. 按规则判定等级 ScoringRule rule JSON.parseObject(scale.getScoringRule(), ScoringRule.class); String level rule.judgeLevel(totalScore); // 4. 落库 AssessmentRecord record new AssessmentRecord(); record.setUserId(userId); record.setScaleId(scaleId); record.setAnswers(JSON.toJSONString(answers)); record.setTotalScore(totalScore); record.setResultLevel(level); recordMapper.insert(record); // 5. 触发预警 if (rule.needWarning(totalScore)) { Warning warning new Warning(); warning.setRecordId(record.getId()); warning.setUserId(userId); warning.setLevel(rule.warningLevel(totalScore)); warningMapper.insert(warning); } return new AssessmentResult(totalScore, level, rule.getDimensions(answers)); } }逻辑说明第一步校验答案数量是关键前端可能因为网络问题漏传如果不校验计分结果会偏低导致该预警的没预警。第二步总分计算用 Stream 一行搞定注意answers的 value 是选项分值不是选项下标前端传参时要转换好。第三步等级判定走 JSON 配置不硬编码。第五步预警触发是异步还是同步我建议同步因为预警数据量小同步写入能保证事务一致性异步反而增加复杂度。参数说明answers的 key 是题号从 1 开始value 是选项分值。如果前端传的是选项下标0 开始后端要加 1 或者前端转换这个接口约定必须在 API 文档里写死否则联调时必翻车。3.2 预警规则怎么设计才不误报预警逻辑是这类系统最容易被答辩老师追问的地方。简单按总分一刀切会误报——一个学生可能只是最近压力大总分偏高但不代表有危机。我一般设计三级预警级别触发条件处理方式1级关注总分超阈值 或 某因子分超阈值系统标记咨询师月度查看2级预警总分超阈值 且 关键因子抑郁、焦虑超阈值咨询师一周内约谈3级危机特定题目如自杀意念题选最高分立即通知咨询师24小时内干预关键因子和危机题目的配置也放在scoring_rule里{ warningRules: { level1: {totalScore: 200, anyDimension: 2.5}, level2: {totalScore: 250, keyDimensions: [抑郁, 焦虑], dimensionScore: 3.0}, level3: {criticalQuestions: [15, 30], criticalScore: 5} } }这样设计的好处是咨询师可以根据学校实际情况调整阈值不用改代码。我帮一个学校调过他们把 level1 的总分阈值从 200 降到 180因为发现很多学生卡在 190 左右被漏掉。这种调整如果硬编码每次都要重新部署。3.3 因子分计算与结果展示SCL-90 这类量表需要算因子分展示给学生和咨询师看。因子分计算逻辑public MapString, Double getDimensions(MapInteger, Integer answers) { MapString, Double result new HashMap(); for (Dimension dim : rule.getDimensions()) { double sum 0; for (Integer qNo : dim.getQuestions()) { sum answers.getOrDefault(qNo, 0); } // 因子分 该因子总分 / 题目数 result.put(dim.getName(), sum / dim.getQuestions().size()); } return result; }注意getOrDefault的兜底防止某题没答导致 NPE。因子分保留两位小数前端用雷达图展示学生能直观看到自己哪个维度偏高。这里有个细节因子分是均分不是总分展示时要标注清楚否则学生会误以为分数越高越好。4. 隐私保护与数据脱敏心理数据比普通业务数据敏感十倍4.1 哪些字段必须脱敏心理测评数据属于敏感个人信息一旦泄露后果严重。我一般做三层防护第一层数据库存储脱敏。学生姓名不存明文存加密后的值查询时用学号关联。手机号存前三位后四位中间用星号。这个在 MyBatis 的 TypeHandler 里做MappedTypes(String.class) public class PhoneTypeHandler extends BaseTypeHandlerString { Override public void setNonNullParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) throws SQLException { // 存储时加密 ps.setString(i, AESUtil.encrypt(parameter)); } Override public String getNullableResult(ResultSet rs, String columnName) throws SQLException { String encrypted rs.getString(columnName); return encrypted null ? null : AESUtil.decrypt(encrypted); } }第二层接口返回脱敏。咨询师查看学生列表时只返回必要字段身份证、家庭住址这些不返回。用 Jackson 的JsonIgnore或者自定义序列化器。第三层日志脱敏。Logback 配置里加过滤器把手机号、身份证号正则替换成星号。这个最容易被忽略但日志文件泄露是常见事故。4.2 权限控制学生只能看自己咨询师看管辖范围权限模型用 RBAC 就够了。学生角色只能查自己的测评记录咨询师能查自己学院的学生管理员查全部。在 MyBatis-Plus 里用拦截器实现数据权限Component public class DataScopeInterceptor implements InnerInterceptor { Override public void beforeQuery(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) { User current SecurityUtil.getCurrentUser(); if (current null || current.getRole() 2) { return; // 管理员不限制 } String originalSql boundSql.getSql(); if (current.getRole() 0) { // 学生只能查自己 String newSql originalSql AND user_id current.getId(); PluginUtils.mpBoundSql(boundSql).sql(newSql); } else if (current.getRole() 1) { // 咨询师查本学院 String newSql originalSql AND user_id IN (SELECT id FROM sys_user WHERE college current.getCollege() ); PluginUtils.mpBoundSql(boundSql).sql(newSql); } } }这个拦截器要注意 SQL 注入风险current.getCollege()如果来自用户输入要转义。实际项目中我一般用参数化查询这里为了演示简化了。另外拦截器只对查询生效更新和删除操作要在 Service 层单独校验权限否则学生可能改别人的记录。4.3 数据导出与匿名化咨询师可能需要导出数据做统计导出时必须匿名化。我一般生成一个匿名 ID 映射表导出文件里用匿名 ID 代替学号映射表单独加密存储只有管理员能解密。这样即使导出文件泄露也无法直接关联到具体学生。5. 避坑与排查部署和联调阶段最容易翻车的五个点5.1 中文乱码从数据库到前端全链路排查现象量表题目里的中文在页面上显示成问号或方块。原因MySQL 连接串没指定字符集或者表创建时用了latin1。很多人只改了数据库默认字符集忘了连接串。解决连接串加useUnicodetruecharacterEncodingutf8mb4建表时显式指定DEFAULT CHARSETutf8mb4。如果已经建了表用ALTER TABLE question CONVERT TO CHARACTER SET utf8mb4转换。前端 Vue 的 axios 请求头也要设Content-Type: application/json;charsetutf-8。5.2 JSON 字段映射失败MyBatis 类型处理器没配现象查询scale表时scoring_rule字段返回 null或者报Cannot convert JSON to ScoringRule。原因MyBatis 默认不认识 JSON 字段到 Java 对象的转换需要自定义 TypeHandler 或者用 MyBatis-Plus 的JacksonTypeHandler。解决在实体类字段上加TableField(typeHandler JacksonTypeHandler.class)并在 Mapper XML 的 resultMap 里指定 typeHandler。如果用 MyBatis-Plus还要在配置类里开启TableName(autoResultMap true)。这个坑我踩过两次每次都是忘了加autoResultMap。5.3 测评提交后分数算错选项分值传成了下标现象学生提交答案后总分明显偏低比如 90 题的量表总分只有 90 分。原因前端传的answers是选项下标0,1,2,3,4后端直接当分值累加导致每题少算 1 分。解决在 API 文档里明确约定传分值还是下标。我一般约定传分值前端从选项对象里取score字段。如果前端已经传了下标后端加 1 修正但要在日志里记录警告推动前端改。5.4 预警不触发事务回滚导致预警丢失现象测评记录写入了但预警表没有数据。原因预警插入和测评记录插入在同一个事务里如果预警插入抛异常整个事务回滚测评记录也没了。或者预警逻辑在事务提交后执行但异步线程拿不到事务上下文。解决预警插入和测评记录插入放在同一个事务里保证一致性。如果预警逻辑复杂拆成独立事务用TransactionSynchronizationManager在事务提交后执行。我一般用同步简单可靠。5.5 并发提交导致重复记录没加唯一索引现象学生快速点击提交按钮产生两条测评记录。原因前端没防抖后端没幂等控制。解决前端按钮点击后置灰后端在assessment_record表加唯一索引UNIQUE KEY uk_user_scale_time (user_id, scale_id, create_time)但create_time精确到秒可能重复更稳妥的是用 Redis 分布式锁key 为assessment:submit:{userId}:{scaleId}过期时间 10 秒。这样同一学生同一量表 10 秒内只能提交一次。6. 进阶技巧把课程设计变成能讲故事的毕设6.1 用因子分雷达图提升演示效果答辩时光展示分数表格很干。我一般加一个 ECharts 雷达图把因子分可视化。学生看到自己的“抑郁因子”明显凸出视觉冲击力强答辩老师也容易记住。实现上后端返回因子分 Map前端用 ECharts 的radar组件渲染const option { radar: { indicator: [ { name: 躯体化, max: 5 }, { name: 强迫症状, max: 5 }, { name: 抑郁, max: 5 }, { name: 焦虑, max: 5 }, { name: 敌对, max: 5 } ] }, series: [{ type: radar, data: [{ value: [2.1, 3.2, 3.8, 2.9, 1.5], name: 本次测评 }] }] };这个图在答辩时能讲出故事该生抑郁和强迫因子偏高建议咨询师重点关注。比干巴巴的“总分 220 分”有说服力得多。6.2 加一个趋势对比功能学生多次测评后可以看分数变化趋势。后端按时间倒序查最近 5 次记录前端用折线图展示。这个功能实现简单但演示效果好能体现“系统不是一次性的有持续跟踪价值”。SQL 用窗口函数SELECT total_score, create_time FROM ( SELECT total_score, create_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) AS rn FROM assessment_record WHERE user_id #{userId} AND scale_id #{scaleId} ) t WHERE rn 5 ORDER BY create_time ASC;注意 MySQL 8.0 才支持窗口函数5.7 要用变量模拟麻烦很多。所以前面选型时我坚持 MySQL 8.0。6.3 部署时用 Docker Compose 一键起答辩演示最怕环境问题。我一般写一个docker-compose.yml把 MySQL、Redis、后端、前端全串起来version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: mental_health ports: - 3306:3306 volumes: - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql redis: image: redis:7-alpine ports: - 6379:6379 backend: build: ./backend ports: - 8080:8080 depends_on: - mysql - redis frontend: build: ./frontend ports: - 80:80 depends_on: - backendinit.sql里放建表语句和初始量表数据docker-compose up -d一条命令起全套。答辩前在笔记本上跑一遍到现场直接演示不用现场装环境。这个习惯帮我省过至少三次答辩翻车。最后说个我自己的教训这类系统最值钱的不是代码是量表数据和预警规则的设计。代码网上抄一套能跑但量表计分规则配错整个系统的结论就是错的。我一般会花半天时间核对 SCL-90 的因子归属确保每道题都在正确的因子里。这个功夫省不得希望帮到你。本文还有配套的精品资源点击获取