职业心理测评系统源码：量表版本、计分引擎与报告生成

简介：职业心理测评系统源码面向开发者、企业HR及心理咨询从业者，聚焦职业倾向、性格特征、工作适应能力、职业满意度与发展风险等标准化量表评估场景，提供兼具测评工具与管理后台功能的完整实现，可辅助职业规划、人才选拔和就业指导。压缩包共2000个文件、约126.45MB，以1815个md测评说明与评分标准为主体，91个js对应前端交互及业务逻辑，json与xml承载配置和数据，另有docx、txt补充量表资料，便于按模块梳理结构。已有270人学习。读者可从中理解用户认证、数据采集、结果生成与反馈展示流程，并参考用户管理、测评结果管理、统计分析和Web与Uniapp多端账号支持等设计，掌握系统架构组织、业务逻辑实现与数据处理方法，适合需要搭建或优化同类测评管理系统的中高级开发者。

1. 从一张手工算分的 Excel 说起：这套职业心理测评系统到底在解决什么

某高校就业指导中心做过一件很原始的事：新生入学发纸质职业兴趣问卷，回收后两位老师对着 Excel 录分，一道题一个格子，录了三天才出完一份年级报告。真正难的不是问卷本身，量表是现成的，难的是收卷、算分、维度归档、出解释这一整条链路全靠人肉。这套职业心理测评系统源码针对的就是这条链路：量表与题库维护、在线施测、自动计分、维度报告、测评档案，外加一套后台管理系统做账号、量表、数据统计。它适合两类人：一类是学校就业中心、企业 HR 想做内部测评又不想买 SaaS 的，另一类是想拿一套完整业务系统练手 Java 全栈的开发者。下面按“能干什么、怎么跑、怎么改”的顺序拆。

2. 技术栈与工程结构：测评管理系统的分层是怎么落到业务上的

拿到源码先不要急着mvn。这类系统最容易出问题的地方不是代码写得好不好，而是分层没切开：题库维护、施测、计分、出报告四条链路耦合在一个 Service 里，后面加一套新量表就得改主流程，那才是真翻车。先看工程骨架。

从目录特征看，后端是 Java 系最常见的组合：Spring Boot 做 Web 层、MyBatis-Plus 做持久层、MySQL 存业务数据、Redis 缓存会话与报告解释文案，前端 Vue 3 + Element Plus 做后台管理端和答题端。原文没写具体版本，我按能跑起来的常见组合给：JDK 17、Maven 3.8+、MySQL 8、Node 18。这套组合的好处是资料多，坏处是版本对不上时启动报错很玄学，后面第 4 章会专门说。

2.1 后端分层与包结构

这套工程的拆法是按“端”和“纯计算”切的，不是按 Controller/Service/Mapper 平铺：

voc-psych/ ├── voc-common/ # 统一返回体 R、全局异常、日期与加密工具 ├── voc-admin/ # 后台管理端：量表维护、账号、统计报表 ├── voc-assess/ # 测评端：开考、取题、交卷、出报告 ├── voc-engine/ # 计分引擎，纯计算，不依赖 Spring Web ├── voc-web/ # 前端 Vue 工程 └── sql/ # 建表脚本 + 演示数据

voc-engine单独拆出来是这套源码里最值得保留的设计。计分规则是业务里最容易变的部分，把它做成一个不依赖 Web、不依赖数据库连接的纯计算模块，就能用单元测试把“某份标准答卷应该得多少分”钉死。我一般会要求新加一套量表前先把标准答卷的单测写好，再动页面，否则改一处反向计分，历史报告全跟着变，连后悔药都没地方买。

测评端的入口 Controller 长这样：

@RestController @RequestMapping("/api/assess") public class AssessController { private final ScaleService scaleService; private final AnswerService answerService; // 开考：把量表版本号固化到本次测评会话里 @PostMapping("/start") public R<StartVO> start(@RequestParam Long scaleId, @RequestParam Long userId) { // 关键：不是取最新量表，而是取当前启用版本，会话绑定版本 ID ScaleVersion version = scaleService.currentVersion(scaleId); AssessSession session = answerService.openSession(userId, version.getId()); StartVO vo = new StartVO(); vo.setSessionNo(session.getSessionNo()); vo.setItems(scaleService.loadItems(version.getId())); return R.ok(vo); } }

参数上scaleId是量表主键，userId从登录态里取更稳妥，这里显式传是为了方便后台“代开考”。返回的sessionNo是一次测评会话的唯一号，后面取题、暂存答案、交卷、查报告全靠它，不要用自增 ID 暴露给前端。openSession里做三件事：生成会话号、写入开始时间、把版本 ID 落库。绑定版本这一步是整个系统能不能做审计的分水岭——量表改过题之后，老报告还得能按老题库解释，靠的就是版本 ID。

2.2 前端页面组织与路由

前端按“答题端极简、管理端重表格”两条线走，路由表能直接看出权限边界：

const routes = [ // 答题端：只依赖 sessionNo，允许未登录扫码进入 { path: '/exam/:sessionNo', component: () => import('@/views/exam/ExamPage.vue') }, { path: '/report/:sessionNo', component: () => import('@/views/exam/ReportPage.vue') }, // 管理端：挂在 Layout 下，meta.roles 控制入口 { path: '/admin', component: Layout, children: [ { path: 'scale', component: () => import('@/views/admin/ScaleList.vue'), meta: { roles: ['ADMIN'] } }, { path: 'item/:scaleId', component: () => import('@/views/admin/ItemList.vue'), meta: { roles: ['ADMIN'] } }, { path: 'archive', component: () => import('@/views/admin/Archive.vue'), meta: { roles: ['HR', 'ADMIN'] } } ] } ]

答题页有一个必须注意的点：量表动辄上百题，一页一题翻页体验好，但用户翻回去改答案时不能每次重新请求接口。常见做法是把已答题目放进sessionStorage，键用sessionNo，交卷时一次性提交全量答案，服务端按题号覆盖写入。管理端则相反，量表列表、题目列表都走服务端分页，前端不做全量缓存，否则几百道题的题库一改就不同步。

2.3 数据库核心表设计

测评类系统的表不多，但字段设计决定了后面能不能扩展。核心四张表：量表、量表版本、题目、作答。

-- 量表主表：一个量表可以有多个版本 CREATE TABLE ps_scale ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scale_code VARCHAR(64) NOT NULL COMMENT '量表编码，如 CAREER_INTEREST', scale_name VARCHAR(128) NOT NULL COMMENT '量表名称', dimension_type VARCHAR(32) NOT NULL COMMENT '维度类型：INTEREST/PERSONALITY/ABILITY', scoring_code VARCHAR(32) NOT NULL COMMENT '计分策略标识，对应 ScoringStrategy.code()', status TINYINT DEFAULT 0 COMMENT '0草稿 1启用 2停用', UNIQUE KEY uk_code (scale_code) ) COMMENT '量表主表'; -- 版本表：发布后不可改题，只能新发版本 CREATE TABLE ps_scale_version ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scale_id BIGINT NOT NULL, version_no INT NOT NULL COMMENT '版本号，从 1 递增', item_count INT DEFAULT 0 COMMENT '题目数量快照', published TINYINT DEFAULT 0 COMMENT '0未发布 1已发布', UNIQUE KEY uk_scale_ver (scale_id, version_no) ) COMMENT '量表版本表'; -- 题目表：dimension_code 决定这道题算进哪个维度 CREATE TABLE ps_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, version_id BIGINT NOT NULL, sort_no INT NOT NULL COMMENT '题序，查询必须按它排序', content VARCHAR(500) NOT NULL, item_type VARCHAR(16) NOT NULL COMMENT 'SINGLE/LIKERT', dimension_code VARCHAR(32) NOT NULL COMMENT 'R/I/A/S/E/C 或 SCL 因子', reverse_flag TINYINT DEFAULT 0 COMMENT '1 表示反向计分题', weight DECIMAL(4,2) DEFAULT 1.00 COMMENT '题目权重', KEY idx_ver_sort (version_id, sort_no) ) COMMENT '题目表';

scoring_code和reverse_flag这两个字段是整套设计的关键。前者让计分规则可以按量表配置，后者把反向题从代码里挪到数据里——很多同类系统把“第 7、12、19 题反向”写死在 Java 里，换一套量表就得改代码重新发版，这种坑踩一次就够。sort_no单独建索引，是因为题目顺序必须稳定，后面第 5 章会讲不排序会出什么乱子。作答表和报告表结构更简单，ps_answer一条记录对应一次会话的一道题，ps_report存维度分 JSON 和解释摘要，这里不占篇幅。

3. 计分引擎拆解：题目、选项、反向分怎么变成一份维度报告

计分是这个系统里唯一不能出错的地方。分数算错了，报告写得再花哨也是废纸。这套源码把计分做成了策略模式，规则从代码里抽到配置上，思路值得照抄。

3.1 题库建模：题干、选项、反向题与维度绑定

题目分两类。一类是单选，选项自带分值，比如“我愿意从事需要动手操作的工作”，五个选项分别 1~5 分；另一类是李克特五级量表，选项固定为“非常不符合”到“非常符合”。两类在存储上统一成ps_item+ps_option，选项表存option_score，这样反向题就不需要在选项上做文章，只需要在题目上打reverse_flag。

维度绑定用dimension_code。以霍兰德职业兴趣为例，六个维度 R/I/A/S/E/C，每道题挂一个维度码，最后按维度累加，取分数最高的三个码组成“RIASEC 三码”。以症状自评类量表为例，维度码换成因子名，比如“躯体化”“焦虑”，一套引擎两种用法。这套抽象的好处是加新量表时后端基本不用改，只在ps_scale.scoring_code上选一个已有策略，或者新写一个策略类。

作答数据结构也要提前设计好。AnswerItem只需要三个字段：题 ID、选项 ID、选项分值。选项分值不要在前端算好再传，前端传了就等于把计分逻辑暴露给用户，改个请求参数就能刷分。正确做法是前端只传选项 ID，后端按ps_option反查分值。

3.2 计分策略：把规则从代码里抽出来

策略接口只做两件事：声明自己的标识，接收版本和答案返回结果。

public interface ScoringStrategy { /** 与 ps_scale.scoring_code 一一对应 */ String code(); /** 纯函数：给定版本快照和答案，返回各维度得分 */ ScoreResult score(ScaleVersion version, List<AnswerItem> answers); }

默认的累加策略实现如下，反向题和权重都在这里处理：

@Component public class LikertSumStrategy implements ScoringStrategy { @Override public String code() { return "LIKERT_SUM"; } @Override public ScoreResult score(ScaleVersion version, List<AnswerItem> answers) { // 维度分用 BigDecimal，避免 0.5 权重被 int 截断 Map<String, BigDecimal> dim = new HashMap<>(); for (AnswerItem a : answers) { Item item = version.itemMap().get(a.getItemId()); if (item == null) { continue; // 答案里有不属于本版本的题，直接跳过而不是抛异常 } BigDecimal raw = BigDecimal.valueOf(a.getOptionScore()); // 反向题：5 级量表用 (max + 1 - raw) 翻转 if (item.getReverseFlag() == 1) { int max = version.getMaxOptionScore(); // 通常是 5 raw = BigDecimal.valueOf(max + 1).subtract(raw); } // 加权累加：weight 默认 1.00，不配就是原分 raw = raw.multiply(item.getWeight()); dim.merge(item.getDimensionCode(), raw, BigDecimal::add); } return ScoreResult.of(dim); } }

逐段说明。version.itemMap()是版本加载时一次性把题目做成Map<Long, Item>，避免在循环里逐题查库，一百道题就是一百次 SQL，这是最典型的 N+1。reverse_flag的判断放在取值之后、加权之前，顺序不能反——先翻转再乘权重，和先乘权重再翻转，在权重不等于 1 的时候结果不一样。BigDecimal而不是int，是因为不少量表会给某些题配 0.5 或 1.5 的权重，用 int 累加会被静默截断，这种错误在页面上完全看不出来，只有对答案的时候才发现。dim.merge的第三个参数是累加函数，比if (containsKey)干净，也不会漏掉初始值为 null 的情况。

原始分出来之后还有一步常模换算。常见做法是T = 50 + 10 * (x - mean) / sd，mean 和 sd 存在常模表里，按人群（比如“大一男生”“企业员工”）区分。这一步我建议单独放一个NormService，不要把常模常数写进策略类，否则换个人群就得改代码。常模表还得注意一点：样本量太小的常模不要上线，否则测出来的分数看着正常，解释全是错的。

3.3 报告生成：模板配置与维度解释

报告页最容易写成硬编码：标题、雷达图、建议段落全写死在 Vue 里。这套源码的处理方式是“模板 + 组件配置”，报告模板存成一段 JSON：

{ "templateCode": "CAREER_V1", "sections": [ { "key": "summary", "type": "TEXT", "source": "RULE:top3" }, { "key": "radar", "type": "CHART", "dims": ["R", "I", "A", "S", "E", "C"] }, { "key": "advice", "type": "TEXT", "source": "DICT:dimension_advice" }, { "key": "detail", "type": "TABLE", "dims": ["R", "I", "A", "S", "E", "C"] } ] }

前端按type走不同渲染器，TEXT去字典里取文案，CHART交给图表组件，TABLE渲染维度分明细。后端只负责把维度分和一串解释码给出去，不拼 HTML、不生成富文本。这样改版式是改 JSON，改文案是改字典表，两边都不用重新发版。解释文案建议进 Redis，一个维度码对应一段 200 字左右的解释，报告页并发一上来直接查库会拖慢首屏。缓存键用dict:advice:{dimensionCode}:{level}，level 按分数区间分高中低三档，同一维度不同档位的解释不能混用，这是最容易被忽略的细节。

4. 把项目跑起来：建库、改配置、双端启动的完整顺序

环境这一步是新手最容易卡住的地方，按顺序来，别跳步。

4.1 环境与依赖版本

版本对不上的典型症状是启动时报Unsupported class file major version，或者前端npm install卡在 node-sass 编译。遇到后者不要硬扛，换 Node 18 重装依赖比改编译参数快得多。

4.2 建库与初始化数据

先建库再导脚本，脚本里包含建表和一份演示量表（约 60 题），够跑通整条链路。

# 1. 建库，字符集必须 utf8mb4，否则题目里的特殊符号会变问号 mysql -uroot -p -e "CREATE DATABASE voc_psych DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;" # 2. 导入表结构与演示数据 mysql -uroot -p voc_psych < sql/schema.sql mysql -uroot -p voc_psych < sql/demo_data.sql # 3. 验证：应该能看到量表、题目、账号三张表有数据 mysql -uroot -p voc_psych -e "SELECT scale_code, scale_name, status FROM ps_scale;"

演示数据里一般会带一个管理员账号，密码是加密后的串，登录不上就去看sys_user表的password字段用的是哪种加密方式，常见是 BCrypt，也有源码图省事用 MD5，两种情况登录逻辑不一样。这一步不做验证直接启动，后面登录失败会误以为是前端问题，白折腾半小时。

4.3 配置与启动

配置文件改四处就够：数据源、Redis、JWT 密钥、报告落盘目录。

server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/voc_psych?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver # Boot 2.x 是 spring.redis，3.x 挪到 spring.data.redis，按版本改前缀 redis: host: 127.0.0.1 port: 6379 database: 3 voc: jwt: secret: change-me-before-prod # 上线前必须换，否则 token 可被伪造 expire-minutes: 120 report: store-path: /data/voc/report # PDF 报告目录，需提前建好并给写权限

serverTimezone不写会出The server time zone value is unrecognized；database: 3是为了和本地其他项目隔开，避免键冲突把别人的缓存冲掉；store-path目录不存在时导出报告会抛FileNotFoundException，但这个异常往往被全局异常处理器吞成“系统繁忙”，排查起来很费劲，建议启动时做一次目录可写校验。

启动顺序是先后端后前端：

# 后端：跳过测试打包，第一次跑建议加 -DskipTests mvn clean package -DskipTests java -jar voc-admin/target/voc-admin.jar --spring.profiles.active=dev # 前端：装依赖、起 dev server cd voc-web npm install npm run dev

后端起来看日志里有没有Started Application in x seconds，前端起来看控制台有没有代理地址。vue.config.js或vite.config.js里的proxy要指到http://127.0.0.1:8080，指错了就是一片 404，但页面本身是能打开的，很容易误判成接口没写。

4.4 一次完整测评的验证路径

跑通不等于能用，按这条路径走一遍才算验证：

1. 用管理员登录后台，进“量表管理”，确认演示量表状态是“启用”，点进题目列表看题数和排序。
2. 新建一次测评会话，拿到sessionNo，用答题端地址/exam/{sessionNo}打开。
3. 全部答完交卷，看返回体里的维度分是不是 6 个（霍兰德）或对应因子数。
4. 打开/report/{sessionNo}，确认雷达图和文字解释都有内容。
5. 回后台“测评档案”，确认这条记录在列表里，点详情能看到原始答案。

第 3 步最容易暴露问题：如果维度分只有一个或干脆是空对象，八成是题目的dimension_code没填或者和策略里取的对不上。这一步对上了，后面的报告和档案基本不会有大问题。

5. 常见问题排查：分数对不上、登录态丢失、重复交卷这几类坑

5.1 页面算 62 分，库里存 58 分

现象：同一份答卷，答题页交卷后展示的分数和报告页、后台档案里的分数不一致，差几分。

原因：前后端各写了一份计分逻辑。前端为了即时展示，用max - raw处理反向题；后端用max + 1 - raw，五级量表下正好差 1 分，几道反向题差出 4 分。另一个来源是维度分用int累加，权重 0.5 的题被截断。

解决：计分逻辑只保留后端一份，前端交卷后直接拿后端返回的维度分渲染，不做本地预计算。分数类型统一BigDecimal，序列化时保留一位小数。补一份标准答卷的单元测试，把每道题的期望分值写死：

@Test void should_match_standard_answer_sheet() { // 固定 60 题答案，其中第 7、12、19 题为反向题 List<AnswerItem> answers = StandardSheet.load("career_demo.json"); ScoreResult r = new LikertSumStrategy().score(version, answers); // 期望值来自人工核算过的标准答案，不能改 assertEquals(new BigDecimal("58.0"), r.get("R")); assertEquals(new BigDecimal("62.0"), r.get("I")); }

这份测试的价值在于，后面任何人改计分策略，跑一次就知道有没有影响历史口径。

5.2 刷新页面就 401，接口时好时坏

现象：登录成功，跳转正常，一刷新就回登录页；有时候不刷新，隔几分钟点菜单也 401。

原因：token 存在sessionStorage，新开标签页或刷新后某些路由守卫读不到；后端拦截器没有放行OPTIONS预检请求，跨域场景下浏览器先发预检，被拦成 401；另外 token 过期时间和 Redis 中登录态的 TTL 各配各的，一个 120 分钟一个 30 分钟，30 分钟后 Redis 键没了但 token 还在。

解决：token 统一存localStorage，请求拦截器里注入Authorization头；拦截器放行OPTIONS和/api/auth/login；过期时间只留一个配置源，Redis TTL 由expire-minutes推导，不要两处手写。

5.3 题目顺序每次打开都不一样

现象：同一个sessionNo，用户退出再进来，题序变了，用户以为系统换了卷子，投诉到管理员那里。

原因：题目查询 SQL 没写ORDER BY。MySQL 在没有明确排序时返回顺序取决于执行计划和数据页存储，数据一变动顺序就漂。分页答题时每页单独查一次，页与页之间的题还可能重复或漏掉。

解决：ps_item上的sort_no不是摆设，所有题目查询强制ORDER BY sort_no ASC；开考时把题序固化进会话快照，后续取题按快照顺序返回，量表版本更新也不影响正在进行中的测评。这条改完之后，题目乱序类的问题基本绝迹。

5.4 用户连点两次提交，档案里出现两条记录

现象：网络慢的时候用户连点交卷，后台档案里同一人同一量表出现两条记录，报告也生成两份，统计口径直接翻倍。

原因：前端按钮没有 loading 锁，后端没有幂等控制，ps_session上也没有唯一约束。

解决：前端点击后立即置submitting并禁用按钮，请求结束再放开；后端给ps_session.session_no加唯一索引，交卷接口捕获DuplicateKeyException后直接返回已有结果而不是报错。两层都做，前端防手抖，后端防重放。

5.5 导出的 PDF 中文全是方块

现象：报告页在浏览器里显示正常，点“导出 PDF”下载下来，中文变成方块或直接空白。

原因：服务器上没有中文字体，PDF 生成库用的是默认字体，找不到中文字形就渲染成方块。开发机上装了字体所以本地测不出来。

解决：把一份开源中文字体打进资源目录，代码里显式注册字体再渲染，不要依赖系统字体；容器部署时把字体目录挂进去或者写进镜像。这个问题每次上线换环境都会复现一遍，属于典型的“本地好好的”类故障。

6. 二次开发：加一套新量表和一套新报告模板的改造路径

真正落地的时候，需求方十个里有八个会提“我们还想加一套 XX 量表”。这套源码的扩展点集中在五处，照着改基本不用动主流程：

加计分策略的写法就是把接口实现一遍，注册成 Bean 即可，工厂按code()自动发现，不需要改任何 if-else：

@Component public class HollandSixStrategy implements ScoringStrategy { @Override public String code() { return "HOLLAND_6"; // 与 ps_scale.scoring_code 保持一致 } @Override public ScoreResult score(ScaleVersion version, List<AnswerItem> answers) { Map<String, BigDecimal> dim = new HashMap<>(); for (AnswerItem a : answers) { Item item = version.itemMap().get(a.getItemId()); // 霍兰德按维度直接累加，不做反向，权重恒为 1 dim.merge(item.getDimensionCode(), BigDecimal.valueOf(a.getOptionScore()), BigDecimal::add); } // 取前三码，分数相同按 R I A S E C 固定顺序兜底，保证结果可复现 return ScoreResult.of(dim).withTopCodes(3, "RIASEC"); } }

改造完之后怎么验证，我的习惯是三步走：先用一份人工核算过的标准答卷跑单测，确认维度分和预期一致；再用测试账号在页面上完整走一遍开考到出报告；最后打开历史档案，确认老报告没有被新策略影响。第三步最容易被跳过，但恰恰是最关键的——策略是按scoring_code路由的，如果新策略的code()和某个老量表撞了名，历史报告会在没有任何报错的情况下按新规则重算，等发现时已经过去半个月了。

还有一个技巧值得说：报告模板尽量只改 JSON 不改代码。需求方提“建议部分想分三档写”，那就去字典表加档位键，前端渲染器一行不动；提“想加一张柱状图”，那就在sections里加一个type: "BAR"的配置项，把渲染器补上就完事。反过来，如果一开始就把报告写成后端拼字符串，后面每改一个字都要发版，那种痛只有维护过的人懂。

从那以后我每次接一套新量表，都强制先把标准答卷的单测写好，再动任何一行计分代码——分数这东西一旦错了，解释写得越漂亮越像黑匣子。希望帮到你。

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