简介：这套职业心理测评系统源码面向企业HR、心理咨询师、教育就业指导人员及前后端开发者，提供从用户认证、量表作答、结果生成到数据统计的一站式管理平台，可用于职业规划、人才选拔和就业辅导等场景；源码包含用户管理、测评结果管理、数据分析等模块。压缩包共2000个文件，以1815个Markdown说明文档为主，另有91个JavaScript脚本、60个JSON配置、25个XML数据文件及2份Word版评分标准，总大小126.45MB；源代码覆盖前端交互、后端逻辑与数据库配置，并支持Web与Uniapp多端访问，md便于查看与二次开发，docx可直接作为测评评分参考。目前已有269人学习，适合想掌握测评系统架构、业务逻辑或快速搭建自有职业测评平台的开发者，也能为管理端的用户管理、测评结果汇总与数据分析提供完整参考实现。
1. 职业心理测评系统：一套能直接上线的题库-测评-报告闭环
去年帮某公司做人才盘点，HR 还在用 Excel 发问卷、人工算分，一份 60 题的职业倾向测评，从发放到出报告要整整一周。后来我把这套职业心理测评系统源码拆完、跑通、部署上线，整个过程让我确认了一件事：这类测评管理系统的核心难点，根本不在问卷页面，而在量表维度计算和报告生成规则上。这个项目是一套前后端分离的测评管理系统，支持题库维护、在线答题、自动计分、报告生成、用户与角色权限管理，覆盖了从「创建量表」到「导出测评报告」的完整业务闭环。适合需要做人才测评、就业指导、心理咨询的团队，也适合想学习真实业务系统前后端分层写法的开发者——你能直接看到一套可运行的工程实践，而不是零散 Demo。
2. 项目概览与技术选型：这套测评管理系统到底分成哪几块
2.1 功能地图：从权限到报告的一整条链路
这套系统从业务上可以切成五个模块：用户权限、题库量表、在线测评、报告中心、数据看板。用户权限负责管理员、测评师、受测者三种角色的登录与数据隔离；题库量表模块维护测评题目、选项分值、维度归属；在线测评模块负责答题页的题目渲染、提交计分；报告中心根据答题结果生成个人报告和群体报告；数据看板展示测评完成率、各维度均值等统计信息。
模块之间是串行依赖关系：建量表 → 发布测评任务 → 受测者答题 → 系统自动算分 → 生成报告。值得注意的是，量表和测评任务是分离的，同一个量表可以被多个测评任务引用，这样在批量做校招测评时，只需创建一个量表再复制任务即可，不需要重复维护题目数据。
2.2 技术栈与分层思路：前后端分离加轻量缓存
这是一个标准的前后端分离工程，后端用的是 Spring Boot 2.x + MyBatis Plus，前端是 Vue 2 + Element UI，数据库用 MySQL，缓存用了 Redis。整体没有引入过于复杂的微服务架构，保持单体应用的简单性，便于二次开发和部署。
| 层次 | 技术选型 | 职责 |
|---|---|---|
| 前端 | Vue 2 + Element UI | 答题页、管理后台、报告展示 |
| 后端 | Spring Boot 2.x | 业务接口、鉴权、计分引擎 |
| 持久层 | MyBatis Plus | 数据访问、分页查询 |
| 数据库 | MySQL 5.7+ | 存储用户、题目、量表、报告数据 |
| 缓存 | Redis | 答题 session 状态、验证码、热点数据 |
后端按 controller-service-mapper 三层分包，业务逻辑集中在 service 层，计分引擎单独抽了一个模块，不跟普通的 CRUD 业务混在一起。我拆这个项目的时候发现，作者把「计分引擎」从测评服务里独立出来，是这套代码最值得看的地方——它使得新增一个量表只需要写一套计分规则，而不用改任何接口代码。
3. 核心模块拆解：测评引擎与报告生成的完整链路
3.1 答题提交：从 request 到原始分结算
测评的核心入口是提交答卷。前端在答题页把用户每道题的选项 ID 组装成数组，一次性提交到后端。后端接参的 DTO 只包含三个字段：任务 ID、用户 ID、答案列表。这里的重点是答案列表的校验——必须先确认题目属于该量表，防止越权提交不存在的题目。
@PostMapping("/api/assessment/submit") public Result<Long> submitAnswer(@RequestBody AnswerSubmitDTO dto) { // 1. 校验测评任务是否处于进行中状态 AssessmentTask task = taskService.getValidTask(dto.getTaskId()); if (task == null || task.getStatus() != 1) { return Result.error("测评任务不存在或已关闭"); } // 2. 校验答案数量与量表题目数量一致 List<AnswerItem> answers = dto.getAnswers(); Integer totalQuestion = questionService.countByScaleId(task.getScaleId()); if (answers.size() != totalQuestion) { return Result.error("答题数量不完整，请检查后重新提交"); } // 3. 逐题落库并计算原始分 Integer rawScore = 0; for (AnswerItem item : answers) { QuestionScore score = questionService.getScoreByOption(item.getQuestionId(), item.getOptionId()); rawScore += score.getScoreValue(); answerRecordService.saveAnswer(userId, item, score.getScoreValue()); } // 4. 调用计分引擎，生成报告并返回报告ID Long reportId = scoreEngine.calculateAndGenerate(task.getScaleId(), rawScore, dto.getAnswers()); return Result.success(reportId); }这段代码的逻辑很直白，但有三个细节值得说。第一，任务状态校验放在最前面，如果测评任务被管理员关闭，受测者看到的直接是友好报错，而不是数据异常；第二，答题数量必须和量表题目数严格相等，防止前端漏传题目，这个校验不能省，否则会出现算分时维度缺失；第三，原始分在循环里同步累加，省去了后续再查一遍表的时间。
参数说明：AnswerSubmitDTO的taskId是测评任务 ID，一个任务对应一个量表；answers列表里每个AnswerItem包含questionId和optionId，后端根据这两个字段去题库表查选项分值。原始分保存在answer_record表里，后续出报告并不重新计算原始分，而是直接读取计分结果，这样既避免重复计算也保留了历史快照。
3.2 维度分数计算：原始分如何变成可解释的结论
大多数职业心理测评并不直接使用原始分，而是把题目按维度分组，比如「进取性」「抗压性」「社交倾向」各含若干题，每个维度的原始分需要对照常模表转换为标准分或百分位。这套系统的计分引擎核心就在这里——它读取量表的维度配置，将原始分映射为 1 到 10 的标准分，再对应到文字描述。
public Report calculateAndGenerate(Long scaleId, Integer rawScore, List<AnswerItem> answers) { // 1. 加载量表维度配置 List<ScaleDimension> dimensions = dimensionMapper.selectByScaleId(scaleId); // 2. 按维度归类题目，计算每个维度的原始分 Map<Long, Integer> dimRawScoreMap = new HashMap<>(); for (AnswerItem answer : answers) { QuestionInfo question = questionMapper.selectById(answer.getQuestionId()); dimRawScoreMap.merge(question.getDimensionId(), scoreMapper.getOptionScore(answer.getOptionId()), Integer::sum); } // 3. 对照维度常模表，将原始分转为标准分 List<DimensionResult> results = new ArrayList<>(); for (ScaleDimension dim : dimensions) { NormItem norm = normMapper.findByDimensionId(dim.getId()); int standardScore = convertToStandardScore(dimRawScoreMap.get(dim.getId()), norm); String levelDesc = levelDescMapper.getByDimensionAndScore(dim.getId(), standardScore); results.add(new DimensionResult(dim.getId(), dim.getName(), standardScore, levelDesc)); } // 4. 生成综合报告文本 String reportText = buildReportText(results); return reportService.save(scaleId, results, reportText); }标准分转换是这个环节最容易藏 bug 的地方。常见做法是采用百分位常模：常模表存了该维度原始分对应的百分位，比如进取性维度原始分 18 分对应第 72 百分位，那么标准分就是百分位除以 10 再四舍五入。转换逻辑单独抽了convertToStandardScore方法，接收原始分和常模对象，内部做区间判断。
参数说明：ScaleDimension包含维度名称、所属量表、题目范围说明；NormItem是常模表记录，包含原始分区间与百分位的映射关系；levelDesc是每个标准分档位对应的评语，比如标准分 8 分对应「进取性突出，喜欢挑战高难度目标」。标准分最终会存到report_dimension_score表，每个维度一条记录，报告页面直接读取这张表渲染图表。
3.3 报告生成：基于模板的组合拼接
报告是整个测评系统价值输出的载体。这套系统没有用复杂的文档生成引擎，而是用「固定模板 + 动态片段」的方式：先根据量表类型选一个报告模板，再把每个维度的标准分和对应评语填进去，最后拼上受测者的基本信息和总体评价。报告以 HTML 片段形式存库，前端直接渲染，也支持导出 PDF。
private String buildReportText(List<DimensionResult> results) { StringBuilder sb = new StringBuilder(); sb.append("<section class=\"report-header\">"); sb.append("<h3>职业心理测评报告</h3>"); sb.append("</section>"); for (DimensionResult result : results) { sb.append("<div class=\"dimension-block\">"); sb.append("<h4>").append(result.getDimensionName()).append("</h4>"); sb.append("<p>标准分：").append(result.getStandardScore()).append("</p>"); sb.append("<p>").append(result.getLevelDesc()).append("</p>"); sb.append("</div>"); } String overall = overallEvaluationMapper.getByTotalScore(calculateTotalScore(results)); sb.append("<div class=\"overall-block\">").append(overall).append("</div>"); return sb.toString(); }报告模板直接拼 HTML 的方式虽然不够优雅，但胜在简单可控。实际拆代码时我注意到，overallEvaluationMapper里存的总体评价是针对「总分区间」的，比如总分在某个区间内是「建议向管理方向发展」，换一个区间又是另一套建议。这意味着管理员可以在后台维护评语，而不用改动代码。
参数说明：DimensionResult的standardScore是 1 到 10 的整数，totalScore是所有维度标准分的总和，用于最终评价的区间判断。这套设计保证了报告生成是纯数据驱动的——新增一个量表只要配好维度和常模，报告模板不需要动。
4. 工程结构与实践：从数据库表到接口再到前端页面
4.1 数据库设计：测评系统里的核心表
拆完代码后我把数据库表梳理了一遍，核心表其实只有四张：scale（量表）、question（题目）、scale_dimension（维度）、answer_record（答题记录）。外围表有assessment_task（测评任务）、report（报告）、norm_item（常模表）、sys_user（用户）。
这里尤其要说明scale_dimension表，它是连接题目和报告的中枢。每一条记录代表量表下的一个维度，包含维度名称、排序号、描述。题目表question通过dimension_id外键关联到维度，报告表通过维度 ID 去查评语。这个设计避免了在每个题目上硬编码维度名称，后续想改维度名只需改一处。
norm_item表我单独拿出来讲，因为这是测评系统的「评分黑匣子」。它存的是原始分区间到标准分的映射关系，比如某维度原始分 10 分到 12 分映射为标准分 4 分，13 分到 15 分映射为标准分 5 分。这个表必须支持后台维护，因为不同职业群体常模不同——对同一个量表，IT 行业和销售行业的常模表可能不一样，系统设计成按行业维度区分常模，这也是这套代码里比较成熟的点。
我用一条建表 SQL 展示关键字段的设计思路：
CREATE TABLE `scale_dimension` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `scale_id` bigint(20) NOT NULL COMMENT '所属量表ID', `dimension_name` varchar(50) NOT NULL COMMENT '维度名称', `sort_no` int(11) DEFAULT '0' COMMENT '排序号', `description` varchar(255) DEFAULT NULL COMMENT '维度说明', `status` tinyint(1) DEFAULT '1' COMMENT '状态：1启用 0停用', PRIMARY KEY (`id`), KEY `idx_scale_id` (`scale_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='量表维度表';norm_item表则需要额外存一个industry_type字段区分常模适用人群：
CREATE TABLE `norm_item` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `dimension_id` bigint(20) NOT NULL COMMENT '维度ID', `industry_type` varchar(20) DEFAULT NULL COMMENT '行业类型', `raw_min` int(11) DEFAULT NULL COMMENT '原始分下限', `raw_max` int(11) DEFAULT NULL COMMENT '原始分上限', `standard_score` int(11) DEFAULT NULL COMMENT '标准分', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='常模映射表';4.2 后端接口设计：RESTful 风格与管理端接口
接口整体按 RESTful 风格组织，测评相关接口和管理端接口分开。测评端接口有POST /api/assessment/submit（提交答卷）、GET /api/assessment/task/{id}（获取测评任务详情）、GET /api/report/{reportId}（查看报告）；管理端接口有POST /api/admin/scale（创建量表）、PUT /api/admin/scale（更新量表）、GET /api/admin/scale/list（量表列表，带分页）。
接口设计上有两个值得学习的地方。第一，测评端和管理端接口路径通过/admin区分，权限拦截器只对/api/admin/**做管理员角色校验，测评端则只做登录校验，这样既保证权限清晰又减少了拦截器配置的复杂度。第二，所有接口响应统一封装成Result<T>格式，包含code、message、data三个字段，前端统一处理错误提示，不用每个接口单独写异常处理。
@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }统一响应体在前后端联调时是省心利器。前端 axios 拦截器只需要判断code是否为 200，不是则直接弹出message，不需要每个页面重复写错误分支。我见过不少项目每个接口返回格式都不一样，前端到处写 try-catch，非常痛苦，这套代码在这方面的处理是合格的。
4.3 前端页面与状态联动：答题页和管理后台
前端分成两个独立的页面组：受测者使用的答题页/报告页，以及管理员使用的量表管理后台。答题页逻辑相对简单——进入页面拉取测评任务详情，拿到量表 ID 和题目列表后渲染，用户逐题选择，全部选完才允许提交。这里有一个容易忽略的细节：答题进度条不是做做样子，而是用一个computed属性实时计算已答题数量除以总题数，并且在未答完时禁用提交按钮。
管理后台的复杂度集中在量表配置页。配置一个量表需要：设置量表基本信息、按维度添加题目、配置每个选项的分值、维护常模表。页面采用步骤条组件分四步完成，每一步提交对应的接口。这里最有价值的是「维度题目分配」这个交互——它通过树形表格展示维度和题目的层级关系，管理员可以在一个页面上完成题目归属调整。
// 前端答题进度计算逻辑 computed: { progressPercent() { if (!this.questionList || this.questionList.length === 0) return 0; const answeredCount = this.answerMap.size; return Math.round((answeredCount / this.questionList.length) * 100); }, canSubmit() { return this.answerMap.size === this.questionList.length; } }这段计算逻辑直白但实用，answerMap是questionId -> optionId的 Map，每选一题就set一条记录。这里不直接用数组长度判断，是因为用户可能修改答案，Map 的 key 唯一性保证了计数正确。如果用户跳着答题，进度条和提交按钮的状态也能正确联动，不会出现选完全部题目仍无法提交的 bug。
5. 踩坑排查：测评系统上线路上的五个真实问题
5.1 并发提交导致答题记录重复
现象：用户快速点击提交按钮两次，后台生成了两条答题记录，计分被重复累加。
原因：前端没有在提交期间禁用按钮，后端的校验也没做幂等处理。
解决：前端在submitLoading为 true 时禁用按钮；后端在answer_record表增加task_id + user_id的唯一索引，第二次插入直接报错，业务层捕获异常后返回「请勿重复提交」。
5.2 常模表数据缺失导致算分报空指针
现象：管理员新配了一个量表，没有给某个维度维护常模数据，用户提交答卷后计分报空指针。
原因：normMapper.findByDimensionId查不到记录时返回 null，后续代码直接调用norm.getRawMin()引发异常。
解决：一是计分引擎里加判空逻辑，查不到常模就抛业务异常并提示「该维度未配置常模」；二是在管理端保存量表时校验每个维度是否都配置了常模，否则不允许发布。
5.3 量表停用后历史报告无法查看
现象：管理员把某个量表状态改为停用后，受测者之前生成的报告打不开了。
原因：报告详情接口在查询量表时会做状态校验，停用的量表直接返回错误。
解决：报告详情接口的校验逻辑调整为「报告存在即可查看，不校验量表状态」，只有提交答卷时才校验量表必须启用。这个改动很小，但体现出「历史的归历史，业务的归业务」的边界意识。
5.4 axios 跨域配置在本地联调时失效
现象：前端npm run dev跑在 8080 端口，后端跑在 9090，前端请求接口报跨域错误。
原因：后端CorsFilter允许的域名列表写的是线上地址，本地的http://localhost:8080不在白名单内。
解决：把后端跨域配置改成从配置文件读取允许域名列表，本地环境放行localhost，线上只放行正式域名。这个踩坑经验告诉我们，跨域配置别写死在代码里，环境差异很容易在这里翻车。
5.5 报告中的标准分与原始分对不上
现象：运营反馈某个维度的标准分看起来异常，比如原始分明明是中等偏上，标准分却给了 3 分。
原因：常模表的原始分区间维护错误，比如raw_min和raw_max的边界重叠，导致区间判断命中了错误的分段。
解决：在管理端增加常模区间校验，保存时检查同一维度的区间是否存在重叠，并给常模表加了区间边界说明，如「包含下限，不包含上限」。
6. 二次开发思路：给系统扩展一个新量表要动哪些地方
6.1 新增一个「团队角色」量表的完整改动清单
我从这套代码总结出的经验是：新增量表几乎不需要改 Java 代码，全部靠数据配置完成。具体步骤是：第一步，在scale表插入量表记录，类型选「团队角色」；第二步，在scale_dimension表插入维度，比如「协调者」「推进者」「创新者」；第三步，在question表插入题目，每道题关联到对应维度；第四步，在norm_item表配好每个维度的原始分区间到标准分的映射；最后，在管理后台发布量表，创建测评任务测试。
这套配置化的设计让二次开发效率非常高。我拆代码的时候，把「新增量表需要动代码的点」列了个清单，结果发现只有一种情况需要写代码——如果新量表的计分逻辑不是简单的维度原始分累加，而是涉及反向计分、权重系数或跨维度计算，就需要在计分引擎里增加规则类型支持。常见做法是给ScaleDimension表加一个score_type字段，支持正向、反向、加权三种类型，计分引擎根据类型做不同处理。
6.2 还可以往哪些方向改
这套系统已经能覆盖完整的测评闭环，但我个人觉得有两个方向值得扩展。一是题目随机抽题逻辑，目前是固定题量的量表，如果希望从题库中随机抽取 N 题组成一次测评，需要在assessment_task表里加一个random_question_count字段，并在提交答卷时校验抽题规则；二是报告对比分析，比如把同一部门多人的测评结果放在一张雷达图上做群体分析，后端可以加一个GET /api/report/compare接口，按维度聚合多人标准分，前端用 ECharts 雷达图渲染。
我一般在扩展这类系统时，会强制自己遵循一个原则：先改数据配置，再改接口，最后才动计分引擎。这套代码的模块划分给了很好的扩展边界——只要不破坏「维度-题目-常模-报告」的数据链路，大部分新需求都能靠数据配置解决。希望这篇拆解对你有帮助，拿到源码后建议先从数据库脚本开始读，再跑一次完整的答题流程，你会比直接看代码更快理解这套系统的设计思路。
本文还有配套的精品资源，点击获取
