企业官网建设流程全解析

简介：这是一套面向高校学生、Java初学者及课程设计开发者的大学生心理健康系统完整项目源码，基于SSM（Spring、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 打天下，理由很实在：部署简单、调试直观、课程设计周期内能做完。

技术栈我一般推荐这套组合：

如果你的环境只能用 JDK 8，Spring 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 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 量表表：一个量表一条记录 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停用' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 题目表：选项用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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 测评记录表：一次测评一条，答案存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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 预警表：触发规则后写入，咨询师跟进 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 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有几个设计决策值得说清楚。第一，选项用 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, Map<Integer, Integer> answers) { // 1. 校验答案完整性，防止前端漏传 Scale scale = scaleMapper.selectById(scaleId); if (scale == null || scale.getStatus() == 0) { throw new BizException("量表不存在或已停用"); } List<Question> 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 预警规则怎么设计才不误报

预警逻辑是这类系统最容易被答辩老师追问的地方。简单按总分一刀切会误报——一个学生可能只是最近压力大，总分偏高，但不代表有危机。我一般设计三级预警：

关键因子和危机题目的配置也放在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 Map<String, Double> getDimensions(Map<Integer, Integer> answers) { Map<String, 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 BaseTypeHandler<String> { @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。很多人只改了数据库默认字符集，忘了连接串。

解决：连接串加useUnicode=true&characterEncoding=utf8mb4，建表时显式指定DEFAULT CHARSET=utf8mb4。如果已经建了表，用ALTER TABLE question CONVERT TO CHARACTER SET utf8mb4转换。前端 Vue 的 axios 请求头也要设Content-Type: application/json;charset=utf-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: - backend

init.sql里放建表语句和初始量表数据，docker-compose up -d一条命令起全套。答辩前在笔记本上跑一遍，到现场直接演示，不用现场装环境。这个习惯帮我省过至少三次答辩翻车。

最后说个我自己的教训：这类系统最值钱的不是代码，是量表数据和预警规则的设计。代码网上抄一套能跑，但量表计分规则配错，整个系统的结论就是错的。我一般会花半天时间核对 SCL-90 的因子归属，确保每道题都在正确的因子里。这个功夫省不得，希望帮到你。

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