企业官网建设流程全解析

简介：面向JavaWeb学习者与毕业设计者，这是一份基于SpringBoot+Vue的学生心理咨询评估系统完整项目源码，涵盖学生信息管理、心理评估流程、图片与视频素材维护等模块，能够帮助读者快速搭建前后端分离的评估管理平台。技术实现采用SpringBoot、MyBatisPlus、MySQL、Maven与Vue，JDK1.8环境即可运行，工程结构清晰，适合二次开发与课程设计参考。包内共355个文件，以Java后端逻辑、Vue前端页面、SVG图标、XML配置及JS静态资源为主，压缩包整体约8.26MB；同时附有系统实现说明文档与常用运行脚本，便于快速启动并对照学习。目前已有65人学习查看，整体规模适中，适合需要从零理解心理咨询评估系统设计思路、积累前后端分离项目经验的开发者参考借鉴。项目工程划分了后端服务与前端页面，能直观看到接口调用、数据持久化与组件渲染的完整链路，便于深入理解项目整体运作。

1. 学生心理咨询评估系统：从量表提交到预警结果，Java 后端要拆清哪几层

学生心理咨询评估系统平时看起来不太忙：一周几十条记录。但开学集中测评时，心理中心往往只给 2～3 天采集窗口，一天内可能涌入几千上万份量表。比普通问卷系统更难的是，结果要按维度聚合并做预警分级，之后还要支持咨询师复核、学期对比；同一套量表改版后，历史评估记录不能跟着变化。用 Java 生态落地这类系统，最常见的组合是 Spring Boot + MyBatis-Plus + MySQL，核心链路拆成领域建模、评估引擎、管理 API、生产加固四层。这篇内容适合正在做心理测评、健康档案或类似表单评估系统的后端工程师，照着可用的方案搭骨架，也能把系统里容易漏的边界参数补上。

2. 学生心理咨询评估系统的领域建模：量表、题项与评估记录

先讲一个容易犯的错：项目初期图省事，只用一张 assessment_record 表，把 scale_id、answers_json、score_json 全部塞进去。单次提交功能确实能跑，但后面做“按因子筛选”“按学期对比历史”“追溯旧版本计分”时会发现 JSON 字段无法在 SQL 里高效筛选，只能写扫表后反序列化的垃圾代码。所以领域建模第一件事就是拆表，同时保证评估记录里留着完整的提交现场。

2.1 量表、题项、评估记录三张核心表的设计职责

按稳定职责拆三层：scale 保存量表元数据，scale_item 保存题目，assessment_record 保存一次评估的答案与结果。为什么不把题目直接放进 scale 的 JSON 里？题目数量多，而且选项范围、反向计分标记、所属维度都是后续要参与查询和批量更新的数据，拆成行存才能走索引，也方便版本换代时做 diff。

下面是建表 SQL 的核心部分，按 MySQL 8.0 设计，中文字符集用 utf8mb4：

CREATE TABLE scale ( id BIGINT PRIMARY KEY AUTO_INCREMENT, code VARCHAR(32) NOT NULL COMMENT '量表编码，如 SCL90/SDS/SAS', name VARCHAR(64) NOT NULL COMMENT '量表名称', version_no INT NOT NULL DEFAULT 1 COMMENT '版本号，每改版加 1', dimension_json TEXT NOT NULL COMMENT '维度定义、题项归属和计分阈值', status TINYINT NOT NULL DEFAULT 1 COMMENT '1=启用 0=停用', updated_at DATETIME NOT NULL, UNIQUE KEY uk_scale_code_version (code, version_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='量表定义表'; CREATE TABLE scale_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scale_id BIGINT NOT NULL, item_no INT NOT NULL COMMENT '题号，从 1 开始', content VARCHAR(255) NOT NULL COMMENT '题干', dimension_code VARCHAR(32) NOT NULL COMMENT '所属因子或维度编码', reverse_score TINYINT NOT NULL DEFAULT 0 COMMENT '1=反向计分', UNIQUE KEY uk_scale_item_no (scale_id, item_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='量表题目表'; CREATE TABLE assessment_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, scale_id BIGINT NOT NULL COMMENT '评估时使用的量表 id', scale_version INT NOT NULL COMMENT '评估时量表版本号', detail_json TEXT NOT NULL COMMENT '逐题答案快照，如 {"1":3,"2":5}', score_json TEXT NOT NULL COMMENT '维度得分快照，如 {"depression":3.2}', result_code VARCHAR(16) NOT NULL COMMENT 'LOW/MEDIUM/HIGH 预警级别', status VARCHAR(16) NOT NULL DEFAULT 'SUBMITTED', created_at DATETIME NOT NULL, reviewed_by BIGINT NULL COMMENT '复核咨询师 id', reviewed_at DATETIME NULL, KEY idx_student_created (student_id, created_at), KEY idx_scale_status (scale_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评估记录表';

我故意没把选项定义拆成一张 option 表：绝大多数心理量表的五档选项是固定的（没有/轻度/中度/偏重/严重），对应 1～5 分，不需要每道题重复存一遍 option 列表。如果将来某个量表选项特殊，在 scale_item 上加 option_json 字段就够，全局拆选项表只会让查询和前端渲染都更啰嗦。

2.2 Java 实体与 MyBatis-Plus 映射

服务端用 Spring Boot + MyBatis-Plus 时，实体类直接对应表名。Scale 里 dimension_json 在 Java 侧先按 String 接收，等进入评估引擎时再统一解析成领域对象，不要在 Controller 层到处拆 JSON。

@Data @TableName("scale") public class Scale { @TableId(type = IdType.AUTO) private Long id; private String code; // 量表编码，如 SCL90 private String name; private Integer versionNo; // 每次发布新计分规则，版本号递增 private String dimensionJson; // 维度、题项归属、阈值，引擎里一次解析 private Integer status; // 1=启用，0=停用 @TableField(fill = FieldFill.INSERT_UPDATE) private LocalDateTime updatedAt; }

@Data @TableName("assessment_record") public class AssessmentRecord { @TableId(type = IdType.AUTO) private Long id; private Long studentId; private Long scaleId; private Integer scaleVersion; // 评估时锁定的版本快照 private String detailJson; // 原始答案明细，用于历史重算 private String scoreJson; // 维度得分结果快照 private String resultCode; private String status; private LocalDateTime createdAt; private Long reviewedBy; private LocalDateTime reviewedAt; }

时间字段统一用 LocalDateTime，不要用 java.util.Date，能省掉一批 MyBatis 类型转换相关的 TypeHandler。

2.3 版本快照与只读历史记录

scale 表的唯一键是 (code, version_no)，每次发布新版本就新增一行，旧行继续留档。提交评估时拿当前 status=1 的版本，把 scaleVersion、detailJson、scoreJson 一并写入评估记录。这样半年后咨询师回看，界面还原的是当时的题面和答案，完全不受新版本影响。

这里有个非常容易被忽略的坑：上线第二版量表之后，历史记录的详情页如果直接用 scale_code 关联最新版量表，所有题项内容和维度定义都会错位，预警结果的解释也会对不上。我一般会在详情接口里强制要求按 record.scale_version 反查当时版本，而不是走默认的最新版。历史评估记录原则上不 UPDATE；真要调整计分结果，必须通过迁移任务生成新版本记录，保留审计链路。

下一章开始写真正的计算逻辑，这是评估系统与普通问卷系统拉开差距的地方。

3. 评估核心引擎：Java 代码把逐题答案算成维度得分与预警级别

算分逻辑如果散落在 Controller 里，后续无论是报表模块还是批量导入工具都得抄一份一模一样的代码，改一处漏三处。我会把计分收敛成一个 ScoringEngine 领域服务，Web 请求、Excel 批量导入、历史数据重算全部走同一个入口。

3.1 提交流程里的请求参数与语义校验

前端提交的数据是“题号到分数”的映射。注意加个 termKey 字段，它表示“学期 + 批次”，因为心理中心会在一个学期里发起多轮评估，幂等键只按 studentId + scaleCode 判断会把第二轮的提交误判成重复。

@Data public class AssessmentRequest { @NotBlank(message = "scaleCode 不能为空") private String scaleCode; @NotBlank(message = "termKey 不能为空") private String termKey; @Valid @NotEmpty(message = "answers 不能为空") private List<ScaleAnswer> answers; } @Data public class ScaleAnswer { @NotNull(message = "题号不能为空") private Integer itemNo; @Min(value = 1, message = "得分最小为 1") @Max(value = 5, message = "得分最大为 5") private Integer score; }

参数校验用 javax.validation 的三组注解就够了，scaleCode 和 termKey 做 @NotBlank，分数用 @Min @Max 控制边界。这里没做“答案覆盖全部必答题”的校验，是因为是否允许漏答属于业务规则，放到引擎里判断更合适。

3.2 维度定义 JSON 与测评算分代码

一份量表的维度定义示例如下，维度归属和阈值都放在 dimension_json 里：

{ "dimensions": [ {"code": "depression", "name": "抑郁", "itemIds": [2,4,5,7,10], "threshold": {"medium": 2.5, "high": 3.5}}, {"code": "anxiety", "name": "焦虑", "itemIds": [1,3,6,8,9], "threshold": {"medium": 2.5, "high": 3.5}} ], "scoring": "AVG", "reverseItemIds": [9] }

scoring 取 AVG 时，维度分 = 该维度下所有题项得分的平均值；取 SUM 时则直接累加，适合总分型量表。reverseItemIds 里放需要反向计分的题号，例如某个题选项 5 的语义是“完全没有”，定义 1 分代表“始终如此”，那这里的分值就要按 6 - score 换算。

引擎核心代码：

@Service public class ScoringEngine { public AssessmentResult evaluate(Scale scale, AssessmentRequest req) { ScaleDefinition def = ScaleDefinition.fromJson(scale.getDimensionJson()); Map<Integer, Integer> answerMap = new HashMap<>(); for (ScaleAnswer answer : req.getAnswers()) { if (!def.containItem(answer.getItemNo())) { throw new ScoringException("题号不属于该量表: " + answer.getItemNo()); } answerMap.put(answer.getItemNo(), answer.getScore()); } Map<String, Double> dimScores = new LinkedHashMap<>(); for (ScaleDimension dim : def.getDimensions()) { double total = 0; for (int itemId : dim.getItemIds()) { Integer value = answerMap.get(itemId); if (value == null) { throw new ScoringException("缺少必答题 itemNo=" + itemId); } // 反向计分：原分值 1-5 换算为 6 - value if (def.getReverseItemIds().contains(itemId)) { value = 6 - value; } total += value; } // 维度分为该维度全部题项的均值，保留两位小数 dimScores.put(dim.getCode(), round(total / dim.getItemIds().size(), 2)); } WarningLevel level = judgeWarningLevel(dimScores, def); return new AssessmentResult(dimScores, level); } private WarningLevel judgeWarningLevel(Map<String, Double> dimScores, ScaleDefinition def) { int highCount = 0; int mediumOver = 0; for (ScaleDimension dim : def.getDimensions()) { double score = dimScores.getOrDefault(dim.getCode(), 0.0); if (dim.getThreshold().getHigh() > 0 && score >= dim.getThreshold().getHigh()) { highCount++; } else if (dim.getThreshold().getMedium() > 0 && score >= dim.getThreshold().getMedium()) { mediumOver++; } } if (highCount >= 1) return WarningLevel.HIGH; if (mediumOver >= 2) return WarningLevel.MEDIUM; if (mediumOver == 1) return WarningLevel.MEDIUM_LOW; return WarningLevel.LOW; } private double round(double value, int digits) { return BigDecimal.valueOf(value).setScale(digits, RoundingMode.HALF_UP).doubleValue(); } }

这段代码的关键点有三处。第一是反向计分先换算再做聚合，后端的展示端不需要知道原题的语义。第二是维度分保留两位小数，预警判断用舍入后的值，避免浮点误差导致恰好等于阈值时判级抖动。第三是判级规则没有简单取最大值，而是考虑了“多个维度同时超中界”的叠加：一个维度超过中界只能算偏低风险，但如果两个维度都超过中界，整体预警等级要升一档。

对代码调用时的异常要映射成业务异常码，不要把 ScoringException 直接抛到前端。常见做法是在 ControllerAdvice 里统一捕获，返回 400 + errorCode，前端按 errorCode 提示“存在漏答题”或“量表已停用”。

3.3 引擎与事务边界的配合

评估提交不单是算分，还要把结果写库。常规做法是提交服务里加 @Transactional，捕获业务异常后标记事务回滚。时序上应先算分再写库，规则变更时便于单测断言。这里再提醒一句：明细快照 detailJson 建议存请求原始答案，不能只存维度得分。否则后期调整计分算法、重新计算历史数据时，只有汇总分没有明细，重算无从谈起。

提示：detailJson 存的必须是原始答案，不能是换算后的分值。否则反向计分规则一旦调整，历史记录无法按新规则重新计算。

4. 学生心理咨询评估管理系统的 Spring Boot API 与权限设计

评估的管理端围绕三个角色展开：学生、咨询师、系统管理员。学生只能看自己的评估记录和结果；咨询师能看被授权分组内的学生记录并出具复核结论；管理员做量表发布和全校统计。

4.1 JWT 的角色声明与咨询师数据权限

JWT payload 我一般只放 userId、role、exp 三个字段，太多自定义声明会让旧 token 在声明调整后失效，排查起来很难受。真正的数据权限不能靠 payload 完成，必须查库。咨询师能看到哪些学生，通过“咨询分组”这个稳定的关联关系控制，而不是直接基于班级。学生在咨询周期内转班，分组关系不受影响才合理。

SELECT r.* FROM assessment_record r JOIN assess_consult_group_student gs ON gs.student_id = r.student_id JOIN assess_consult_group g ON g.id = gs.group_id AND g.counselor_id = #{counselorId} AND g.status = 1 WHERE r.status = 'SUBMITTED' AND r.result_code IN ('MEDIUM', 'HIGH') ORDER BY r.created_at DESC LIMIT #{limit}

查询逻辑里把权限范围直接 join 进 SQL，不要先查出所有学生 ID 再用 IN 分批查。集中评估期间，一个咨询师名下可能是几百个学生，IN 拆批会多出好几个 DB 往返。

4.2 提交阶段的幂等控制：Redis SETNX 与数据库兜底

集中评估期间学生连点两次、前端断线重试都是正常的，后端必须把“同一轮评估只能生成一条记录”兜住。最稳妥的组合是 Redis SetNX 做前置防重，数据库唯一索引做最终兜底。

@Transactional(rollbackFor = Exception.class) public AssessmentRecord submit(Long studentId, AssessmentRequest req) { String idempotentKey = "assess:" + studentId + ":" + req.getScaleCode() + ":" + req.getTermKey(); // SETNX 原子判空写入，二十四小时内同一轮只允许第一笔成功 Boolean first = redisTemplate.opsForValue() .setIfAbsent(idempotentKey, "1", Duration.ofHours(24)); if (Boolean.FALSE.equals(first)) { throw new DuplicateSubmitException("本轮评估已提交"); } Scale scale = scaleMapper.selectActiveScale(req.getScaleCode()); if (scale == null) { throw new ScaleNotFoundException("量表不存在或已停用"); } AssessmentResult result = scoringEngine.evaluate(scale, req); AssessmentRecord record = new AssessmentRecord(); record.setStudentId(studentId); record.setScaleId(scale.getId()); record.setScaleVersion(scale.getVersionNo()); record.setDetailJson(JsonUtil.toJson(req.getAnswers())); record.setScoreJson(JsonUtil.toJson(result.getDimensionScores())); record.setResultCode(result.getWarningLevel().name()); record.setStatus("SUBMITTED"); record.setCreatedAt(LocalDateTime.now()); recordMapper.insert(record); return record; }

为什么要 24 小时？心理中心的单轮评估窗口通常在一周内，24 小时足够覆盖“同一天重复点击”和“网络重试”两种典型场景；超过 24 小时的重复提交，大概率是学生换了另一轮批次，不应再拦截。Redis 不可用时，这段逻辑会退化成依赖数据库唯一索引，所以 assessment_record 表需要加一个唯一键 (student_id, scale_id, term_key)，不能只靠应用层判断。

ALTER TABLE assessment_record ADD COLUMN term_key VARCHAR(32) NOT NULL DEFAULT '', ADD UNIQUE KEY uk_student_scale_term (student_id, scale_id, term_key);

这个唯一索引在正常流程下不会触发，只有在 Redis 数据被清理或网络抖动导致 SetNX 漏判时才会起作用，所以它的存在价值是兜底，而不是替代防重逻辑。

4.3 结果查询的脱敏与最小字段返回

学生、咨询师、管理员看到的字段不同，不要在 entity 上直接序列化，应该按场景组装 VO。姓名通过自定义 JsonSerializer 做掩码，只有管理员能看到完整姓名。具体实现：

public class NameMaskSerializer extends JsonSerializer<String> { @Override public void serialize(String value, JsonGenerator gen, SerializerProvider serializers) throws IOException { if (value == null || value.length() <= 1) { gen.writeString("***"); } else if (value.length() == 2) { gen.writeString(value.charAt(0) + "*"); } else { gen.writeString(value.charAt(0) + "**" + value.charAt(value.length() - 1)); } } }

掩码规则按场景配置，学生端看到“张*”，咨询师端可以看到“张*三”，管理员端拿到完整字段。核心是不要只把 resultCode 暴露成“编码”，配一个 result_desc 帮前端展示预警说明，少写一段前端翻译映射。

5. 上线前必须验证的三个点：并发峰值、索引命中与计分回归

这里不讲大而全的压测方案，只讲三个最能暴露问题的点。

5.1 集中评估日的数据库连接池与事务时长

应用接入层 HikariCP 的 maximum-pool-size 按“CPU 核数 × 2 + 1”起步，4 核机器配置 9，8 核配置 17，不要盲目调到 200。提交事务里涉及一次 Redis 写、一次量表查询、一次 JSON 解析、一次 DB 插入，正常串行耗时应该控制在 30ms 以内；如果超过 100ms，先看是不是把“解析完整 JSON + 正则校验”这类 CPU 密集操作放进了事务里。

5.2 高频筛选维度与索引配置

常见管理端筛选语句是“按学期、按量表、按预警级别、按咨询师”。除了主键索引和 (student_id, created_at)，这几个场景必须覆盖：

核查方式很简单：把管理端常用的三条慢 SQL 拿出来执行 EXPLAIN，看到 type 是 ref 或 range 就够用，不需要对每条查询都建联合索引。

5.3 用 golden sample 校验计分与预警回归

我通常在仓库里放一份固定样例测试，输入同样的答案，断言各维度分和预警级别完全一致。这样改版时只要跑一遍，就能把“算法改坏了但报告页面没报错”的风险降到最低。

@Test void evaluate_multiMedium_returnsMedium() { Scale scale = new Scale(); scale.setCode("TEST"); scale.setVersionNo(1); scale.setDimensionJson("{\"dimensions\":[" + "{\"code\":\"depression\",\"itemIds\":[1,2,3],\"threshold\":{\"medium\":2.5,\"high\":3.5}}," + "{\"code\":\"anxiety\",\"itemIds\":[4,5,6],\"threshold\":{\"medium\":2.5,\"high\":3.5}}" + "],\"scoring\":\"AVG\",\"reverseItemIds\":[]}"); AssessmentRequest req = new AssessmentRequest(); req.setScaleCode("TEST"); req.setTermKey("2024-01"); req.setAnswers(List.of( new ScaleAnswer(1, 3), new ScaleAnswer(2, 3), new ScaleAnswer(3, 3), new ScaleAnswer(4, 3), new ScaleAnswer(5, 3), new ScaleAnswer(6, 3) )); AssessmentResult result = scoringEngine.evaluate(scale, req); assertThat(result.getDimensionScores().get("depression")).isEqualTo(3.0); assertThat(result.getDimensionScores().get("anxiety")).isEqualTo(3.0); assertThat(result.getWarningLevel()).isEqualTo(WarningLevel.MEDIUM); }

注意这里维度分 3.0 同时命中两个因子的 medium=2.5 阈值，却都不触达 high，所以预警结果 MEDIUM。压测时还要用同一条 golden sample 跑批量导入接口，确认入参解析、算分、落库三个环节产出的 score_json 一致。把这段测试加进 CI，发版前不用人工在浏览器里点三十遍量表就能确信计分链路是稳的。

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