职业心理测评系统源码拆解：架构、表结构与部署避坑指南

简介：一份完整的职业心理测评系统源码包，面向需要构建或优化心理测评平台的开发者、企业人事部门及教育机构。系统涵盖职业倾向、性格特征、工作适应能力等标准化量表，支持浏览器与移动应用多端访问，并集成用户管理、测评结果统计与报表输出等管理功能。包体共两千个文件，以一千八百一十五个Markdown说明文档为主，辅以九十一个脚本、六十个配置、二十五个标记文件及两个评分文档，分别承担功能说明、前端交互、数据定义、结构配置和量表评分，压缩后约126.45MB。已有二百六十九人学习下载，适合从源码层面掌握测评系统架构、业务逻辑与数据处理流程；通过阅读脚本与配置可快速理解前端交互及量表配置机制，而说明文档则提供了模块拆解与使用指引。

1. 职业心理测评系统源码能解决什么：它更着重的是“管理”，而不只是一张问卷

某次帮一家公司搭内部测评工具，我一开始也以为职业心理测评系统无非是几道选择题加一个结果页。直到对方 HR 直言：第三方在线问卷没法改题、数据没法私有化、统计结果不能按岗位筛选，最后大家拿到的只有一张张 Excel。有这类痛点的场景并不少见，而这篇要拆的，正是一份可二次开发的职业心理测评系统源码。它本质上是一套完整的管理系统：用户、题库、测评记录、报告、权限、导出统计都收在同一个后台里。

整包跑起来后你会看到三个角色：普通用户注册后参与测评，运营者维护题目并查看记录，管理员统管账号权限和数据。典型实现是基于 Spring Boot 或 SSM 的 B/S 结构，MySQL 里 8 张核心表把全流程数据串起来。适合的人群有两类：一类是拿它做课程设计或毕设，需要完整的前后台流程；另一类是中小企业内部要搭建测评平台，又不想把员工的数据托在外部服务上。如果你只想要 20 道现成的测试题，这个包显得偏重；但如果你想搞明白“测评数据怎么落库、后台怎么把题库管得可维护”，那就找对东西了。

2. 整体架构与数据表结构：用 8 张核心表给代码先做个地图

拿到源码包别急着点启动。我的习惯是先看目录和数据库脚本，这一步半小时能省下后面一整天的翻找时间。测评系统和管理系统在结构上套路非常固定，把表结构和代码路径对上号后，想找任何功能点基本都能直达。

2.1 技术构成：三个角色的模块边界

这套职业心理测评系统是典型的 B/S 后台管理系统：前端页面放在 resources 下的 templates 和 static 目录，后端按 controller/service/mapper 分层，数据库用 MySQL。如果你打开 pom.xml 发现是 Spring Boot + MyBatis，那映射关系最好认；如果是 SSM（Spring + SpringMVC + MyBatis），包结构会多一层 XML 配置，但业务代码的位置几乎不变。

三个角色的模块边界建议提前分清，这对后面定位代码非常有帮助：

• 用户端：首页、注册、登录、测评列表、答题页、报告页，Controller 通常叫 UserController 或 TestController；
• 运营端：题目管理、问卷管理、测评记录查询与导出，入口多在 AdminController 或 QuestionController；
• 管理端：管理员账号维护、角色权限、数据统计、系统参数，通常放在 SystemController。

实际代码里，运营端和管理端经常共用一套后台页面，只是菜单路由不同。打开 templates/admin 目录看看有没有 index.html、question_list.html、record_list.html 这类文件，有的话后台主要功能就集中在这一块。如果看到的是前后端分离的 Vue 工程，那管理端就得单独做一次 npm install，部署流程会多一步。

这里有个选型层面的常见判断：多数测评源码为了减少部署复杂度，做成单体应用，后台页面用 Thymeleaf 渲染；少数拆成前后端分离，是为了后台交互更流畅，但部署时就要多处理跨域和静态资源问题。拿到源码后先确认单体还是分离，直接决定了后面第 5 章里某些坑要不要踩。

2.2 核心表结构：8 张表的关系先理清

有一句话很实在：代码会骗人，数据库不会。哪怕源码包再完整，也要先把表结构过一遍，否则排查问题时很容易对着 Service 层白看半天。

这一类测评系统的核心表模型可以归纳为 8 张：

这里有两张表在建表时要特别留意外键和索引的设计。先看测评记录表：

CREATE TABLE `user_assessment` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL COMMENT '用户ID', `assessment_id` bigint NOT NULL COMMENT '问卷ID', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0未提交 1已完成', `total_score` int DEFAULT NULL COMMENT '总分', `start_time` datetime DEFAULT NULL, `submit_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_assessment_id` (`assessment_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='测评记录表';

逻辑说明：

• status 用 tinyint 而不是字符串，MyBatis 映射成 Integer 后判断更省事，存储上也更紧凑；
• user_id 和 assessment_id 分别建普通索引，覆盖“查某人所有记录”“查某份问卷所有参与记录”两种高频场景。数据量到几万条时，没有这两个索引后台记录页会明显变顿。

再看维度得分表：

CREATE TABLE `dimension_score` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_assessment_id` bigint NOT NULL, `dimension_code` varchar(32) NOT NULL COMMENT '维度编码，如 R/I/A/S/E/C', `score` int NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_assessment_dimension` (`user_assessment_id`,`dimension_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='维度得分表';

逻辑说明：

• dimension_code 用字母编码而不是中文名，是为了后面前端做雷达图或柱状图时数据更干净，展示名称另用映射表；
• UNIQUE 索引 uk_assessment_dimension 防止同一份答卷重复写入多个相同维度分数，这个约束在生产环境里同时充当防重手段。

如果你拿到的源码包里没有 dimension_score 表，说明计分只做了简单总分，没做维度拆分。那后台统计页里“各维度平均分”这一项基本是写死的假数据。这个边界最好在改代码前确认，免得辛苦改完全发现少一张表。

2.3 初始化数据与默认账号：先跑通再改密码

解压目录下一般会有 sql 文件夹，或者把建表和初始化数据写进 resources/db 下。导入命令我常用这种写法：

mysql -uroot -p --default-character-set=utf8mb4 < sql/schema.sql mysql -uroot -p --default-character-set=utf8mb4 < sql/data.sql

命令解析：

• 指定 --default-character-set=utf8mb4 是为了防止终端默认字符集把初始化数据里的中文变成乱码；
• schema 和 data 分开跑的好处是建表失败时更容易定位，不会把表结构和测试数据混在一次导入里，回滚也麻烦。

导入后第一件事是找默认管理员账号。很多源码把管理员写死在 data.sql 里，常见的有 admin / 123456 或 admin / admin123。登录不进去时别急着怀疑代码，先看密码字段是不是 BCrypt 或 MD5 密文；如果库里存的是加密串，而页面直接提交明文，那就是加密方式不匹配。这时候要么用代码里的 PasswordEncoder 重新生成一条密文更新到数据库，要么改写登录逻辑支持明文校验。

注意：默认管理员密码登录成功后，第一件事是在后台改掉。课程设计演示可以事后还原，企业内部部署不改就是裸奔。

3. 本地跑通一次测评：从环境配置到接口拿到报告

第 3 章的目标很明确：让源码在本地跑起来，并且走完一次完整的测评流程。这部分做扎实，后面改代码才有底。

3.1 前置环境：JDK 版本与字符集先锁死

启动前先核对三样东西：JDK 版本、MySQL 版本、Redis 是否在用。

Spring Boot 2.x 项目一般用 JDK 8 最稳，Spring Boot 3.x 则要 JDK 17，否则 java.lang.UnsupportedClassVersionError 直接挡路。打开 pom.xml 里 spring-boot-starter-parent 的版本就能判断该装哪个 JDK。不少源码是 2.x 时代写的，强行配 JDK 17 会因为 javax.servlet 改名成 jakarta.servlet 而编译失败，这个坑属于“看着简单折腾一天”的高发类型。

数据库连接配置在 Spring Boot 里看 application.yml，在 SSM 里看 jdbc.properties。常用配置如下：

spring: datasource: url: jdbc:mysql://localhost:3306/career_test?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: test_user password: test_pass

参数说明：

• characterEncoding=utf8 在 MySQL Connector/J 8.x 里会自动映射到 utf8mb4，不需要写成 utf8mb4；
• serverTimezone 必须配置，否则 JDBC 驱动与 MySQL 时区不一致时，启动过程会直接抛异常；
• 建议单独建一个专用数据库账号，不要长期用 root 跑应用，避免后续权限收不回来。

确认配置后，用 Maven 打包启动：

mvn clean package -DskipTests java -jar target/xxx-system-0.0.1-SNAPSHOT.jar

启动失败就查堆栈第一个 Caused by。最常见两种：

• Access denied for user：账号密码不对，或者 root 只允许 localhost 登录；
• Table doesn't exist：连错了库，或者建库脚本还没执行。

3.2 注册登录与测评页面：前端表单到后端 DTO

用户流程是固定的：打开首页，注册新用户，登录，选择测评，做完所有题目，提交，查看报告。

注册接口通常叫 UserController.register，常见实现方式如下：

@PostMapping("/register") @ResponseBody public Result<String> register(@RequestBody RegisterDTO dto) { // 判断用户名是否已存在 User exist = userMapper.selectByUsername(dto.getUsername()); if (exist != null) { return Result.error("用户名已存在"); } // BCrypt 加密后存储 String encodePwd = BCrypt.hashpw(dto.getPassword(), BCrypt.gensalt()); User user = new User(); user.setUsername(dto.getUsername()); user.setPhone(dto.getPhone()); user.setPassword(encodePwd); user.setRole(0); userMapper.insert(user); return Result.ok("注册成功"); }

逻辑说明：

• 用户名判重放在业务代码里，虽然数据库 username 字段也可以建唯一索引，但先查后插能返回更友好的提示；
• BCrypt.gensalt() 每次生成随机盐，相同密码加密出的密文也不一样，比固定盐的 MD5 安全很多；
• 如果发现源码用的是 MD5，我一般会顺手替换成 BCrypt，改动范围集中在注册和登录两个方法，不影响表结构。

前端页面用普通 HTML + jQuery 就能提交，请求方式如下：

fetch('/register', { method: 'POST', headers: { 'Content-Type': 'application/json;charset=utf-8' }, body: JSON.stringify({ username: 'test01', phone: '13800000000', password: 'abc123456' }) }).then(res => res.json()).then(data => { if (data.code === 200) { location.href = '/login?username=' + data.data; } else { alert(data.msg); } });

注意一个细节：如果登录态用 session 保存，而且依赖 Redis 做 session 共享，那必须先启动 redis-server，否则登录接口会直接报连接超时。判断方法很简单，看 application.yml 里有没有 spring.redis 配置。

3.3 答题提交与结果计算：核心循环为什么容易写错

提交接口是整个系统最核心的一段。常见实现是把每道题的选项分累加，然后批量写入答题明细：

@PostMapping("/submit") @ResponseBody public Result<String> submit(@RequestBody SubmitDTO req) { // 创建一份测评记录 Long uaId = userAssessmentMapper.create(req.getUserId(), req.getAssessmentId()); List<UserAnswer> answerList = new ArrayList<>(); int totalScore = 0; for (AnswerItem item : req.getAnswers()) { Option opt = optionMapper.selectById(item.getOptionId()); UserAnswer record = new UserAnswer(); record.setUserAssessmentId(uaId); record.setQuestionId(item.getQuestionId()); record.setOptionId(opt.getId()); record.setScore(opt.getScore()); answerList.add(record); totalScore += opt.getScore(); } // 批量插入明细 userAnswerMapper.batchInsert(answerList); // 更新总分 userAssessmentMapper.updateTotalScore(uaId, totalScore); // 生成报告 reportService.generate(uaId); return Result.ok("提交成功"); }

逻辑说明：

• batchInsert 一次插入多行，比单条循环 insert 少很多次网络往返，60 道题时性能差异明显；
• totalScore 直接从 Option.score 累加，要求建题库时就把反向计分题的分数预先处理好。比如“我很少主动发言”这类反向题，选项分应当自减，而不是像正向题一样顺序递增，否则看起来一切正常，结果全是反的；
• 报告生成放在事务里会让提交接口多等几十毫秒。单机演示无所谓，多人同时提交时建议把报告生成挪到异步，这个第 6 章会展开讲。

参数上还有一个容易被忽略的点：SubmitDTO.answers 里的 questionId 在后端没有校验是否属于该 assessment。如果前端题目顺序被篡改，一条答卷可能混入别的问卷题。管理系统里数据安全是底线，建议提交时用 assessmentId 查出合法题目集合，再过滤掉不合法的选项，哪怕现在只是课程设计，养成这个习惯也没坏处。

4. 管理端功能拆解：题库维护、记录导出、统计报表三段写法

这套源码的管理属性最集中地体现在后台。把后台这三个功能吃透，基本就掌握了系统管理的整体骨架。

4.1 后台题库维护：一道新增题背后要做的三件事

运营人员日常最常操作的入口是 /admin/question/list。页面表格里显示题目 ID、所属问卷、题面、排序，操作列提供编辑、上下移和删除。新增一道题时，后端一般写成这样：

@PostMapping("/admin/question/save") @ResponseBody public Result<String> save(@RequestBody QuestionSaveDTO dto) { // 先插入题目，拿到自增 ID Question q = new Question(); q.setAssessmentId(dto.getAssessmentId()); q.setContent(dto.getContent()); q.setSortOrder(dto.getSortOrder()); questionMapper.insert(q); // 再批量插入选项，外键指向题目 ID for (OptionDTO o : dto.getOptions()) { Option op = new Option(); op.setQuestionId(q.getId()); op.setOptionName(o.getOptionName()); op.setScore(o.getScore()); op.setSortOrder(o.getSortOrder()); optionMapper.insert(op); } return Result.ok("保存成功"); }

逻辑说明：

• 题目和选项不是同一张表，必须放在同一个事务里，否则题目插成功但选项失败，前端会出现“有题无选项”的残缺数据；
• 选项 score 的类型要看业务是否需要小数，如果只算整数总分，用 Integer 最省事；需要精确小数时改用 BigDecimal，避免 Double 取整误差。

这里还有一个特别容易处理的决定：删除题目时不要真的物理删除。删除题目会把历史答题记录里的引用也弄丢，统计报表立刻少一段真实数据。我的做法是用 status 字段做逻辑删除：把 status 置为 0，前台查询自动过滤，后台保留历史记录。

4.2 测评记录筛选与导出：SQL 拼接和 BOM 两个细节

后台记录页通常支持按用户名、问卷、时间范围、状态筛选。MyBatis 里用 XML 写动态 SQL 比注解拼接更清晰：

<select id="selectRecordPage" resultType="UserAssessmentVO"> SELECT ua.id, ua.user_id, ua.assessment_id, ua.total_score, ua.status, ua.submit_time, u.username, a.name AS assessment_name FROM user_assessment ua LEFT JOIN user u ON ua.user_id = u.id LEFT JOIN assessment a ON ua.assessment_id = a.id <where> <if test="username != null and username != ''"> AND u.username LIKE CONCAT('%', #{username}, '%') </if> <if test="assessmentId != null"> AND ua.assessment_id = #{assessmentId} </if> <if test="startTime != null"> AND ua.submit_time &gt;= #{startTime} </if> <if test="endTime != null"> AND ua.submit_time &lt;= #{endTime} </if> </where> ORDER BY ua.submit_time DESC </select>

逻辑说明：

• LEFT JOIN 保证 user_assessment 里的记录即使关联用户被删除也能显示，统计时不丢数据；
• XML 里大于号和小于号必须写成 > 和 <，直接写 >= 会被 XML 解析器误认成标签开始，启动直接报错；
• 筛选条件建议用 submit_time 而不是 start_time，因为未完成的记录没有提交时间，导出时应排除。

导出测评明细时，很多源码直接用 CSV 或 Excel 工具类。要注意：如果导出的是 CSV 文件，中文乱码问题几乎都出在文件 BOM 上。

byte[] bom = new byte[]{(byte) 0xEF, (byte) 0xBB, (byte) 0xBF}; response.getOutputStream().write(bom);

这段代码在输出流最前面写入 UTF-8 BOM，Excel 才能识别文件编码。文件名也要做 URL 编码，否则浏览器下载后中文名会变成下划线或乱码：

response.setHeader("Content-Disposition", "attachment;filename=" + URLEncoder.encode("测评记录.csv", "UTF-8"));

4.3 后台统计：总测次数与维度平均分实现

统计页一般展示总测评次数、各问卷参与人数、各维度平均分。总次数直接 count 即可：

SELECT COUNT(*) FROM user_assessment WHERE status = 1

维度平均分按 dimension_score 分组聚合：

SELECT ds.dimension_code, AVG(ds.score) AS avg_score FROM dimension_score ds WHERE ds.user_assessment_id IN ( SELECT id FROM user_assessment WHERE assessment_id = #{assessmentId} ) GROUP BY ds.dimension_code

逻辑说明：

• 子查询在数据量大时性能差，但测评系统一般就几千到几万条记录，问题不大；
• dimension_code 如果存的是字母编码，返回结果需要在前端映射成中文标签；如果存的是中文名，图表展示直接，但后续改文案就要动表数据。我更推荐存编码，展示层做映射。

观察点在于：如果源码里没有 dimension_score 表，维度平均分统计就无从谈起，只能在 report.detail 文本里做字符串截取，那种方案非常脆弱，基本不值得继续改。所以你在第 2 章确认表结构时，就要把这个边界看清楚。

5. 部署使用避坑：5 条排查记录，先省两小时冤枉时间

这章的每一条都是被反复问过的问题，按“现象 → 原因 → 解决”来写，方便对号入座。

5.1 总分始终为 0

现象：用户答完 60 道题，提交后报告显示总分为 0，但答题明细里选项分明明有值。

原因：最常见的是前端传入的 optionId 与数据库里实际主键不一致，后端按 optionId 查选项时查到了 null，累加被跳过。另一种可能是 user_answer 表的 score 字段没被 MyBatis 映射上，插入全是 null，导致总分初始值没有被累加。

解决：先去数据库查该答卷对应的 user_answer 表，手算一遍分数是否等于 user_assessment.total_score。如果明细有分而总分是 0，问题就在提交接口的 update 语句上，检查 updateTotalScore 的 SQL 是否真的更新了 total_score 字段。如果明细也没分，回到前端看提交的 optionId 是否错位，测评页面重新绑定后再测一轮。

5.2 后台新增题目，前台看不到

现象：管理后台成功新增 10 道题，前台测评列表还是原来的 30 题。

原因：题目列表被 Redis 缓存了，后台只做了数据库写入，没清缓存。另一种情况是前台查询条件限制了 status=1，而新增题目默认 status=0。

解决：先看前台查询 SQL 有没有 status=1 的条件；再看项目里是否有 Redis 缓存。如果两处都正常，就要检查测评页打开时是否把题目数据加载一次后就放进了内存缓存。我习惯在题目 save 方法末尾显式清一次缓存：

redisTemplate.delete("question:list:" + dto.getAssessmentId());

这样新增后下次查询必然走数据库。

5.3 导出的测评文件打开乱码

现象：后台导出测评记录，下载后用 Excel 打开，中文全乱码，英文和数字正常。

原因：经常是导出的 CSV 文件以 UTF-8 编码保存，但没有写 BOM。Excel 在 Windows 下默认按系统本地 ANSI 编码解析，没有 BOM 就识别错。

解决：输出流开头写三个字节的 UTF-8 BOM，代码在第 4.2 节已经给出。文件名也要用 URLEncoder 编码后再放 Content-Disposition，否则浏览器下载后中文名直接丢失。

5.4 数据库中文全部变成问号

现象：后台新增题目，中文存进数据库变成 ??，用户注册时填的中文也同样。

原因：建库时默认字符集不是 utf8mb4，或者 JDBC 连接串没带 characterEncoding=utf8。

解决：把库和表都转成 utf8mb4：

ALTER DATABASE career_test CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER TABLE question CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

表多时可以用脚本批量转换，但最省心的还是在建库阶段就统一字符集，并在 application.yml 里把编码参数加好。转完字符集后，重启服务再插一条中文数据验证。

5.5 部署后静态资源 404

现象：本地一切正常，部署到服务器后 CSS、JS、图片全部 404，登录页光秃秃一片。

原因：Spring Boot 默认把静态资源放在 classpath:/static/，如果打成 war 包部署到外置 Tomcat，context path 配置不对就会出现静态资源路径错位。还有一种是前端页面引用了绝对路径 /css/xx.css，但项目 context path 带上了二级目录，路径就断了。

解决：先用 java -jar 方式部署，静态资源路径最省心；非要打 war 包，就把页面里的资源引用改成相对路径，或者在 application.yml 里配置 context-path。我倾向直接 jar 部署，少一层 Tomcat 的路径问题，日志排查也更快。

6. 进阶改造：维度计分、雷达图和并发防重三个见效点

6.1 从简单总分到维度计分：给题目表加一个字段

如果源码默认只算总分，想按维度统计也很简单。给 question 表加一列 dimension_code，提交后在 ReportService 里重新遍历答题明细并按维度累加：

Map<String, Integer> dimScore = new HashMap<>(); for (UserAnswer ua : answerList) { Question q = questionMapper.selectById(ua.getQuestionId()); String dim = q.getDimensionCode(); if (dim == null) { continue; } dimScore.merge(dim, ua.getScore(), Integer::sum); }

逻辑说明：

• 这道题归属哪个维度，完全由 question 表的 dimension_code 决定；每道题只属于一个维度，就贪图简单；
• dimension_code 为 null 时直接跳过，避免统计时混进脏数据。

6.2 报告页雷达图：让结果不只在文本里

后台有了维度分，前台报告页就能接 ECharts 画雷达图：

fetch('/report/dimension?userAssessmentId=' + id) .then(res => res.json()) .then(data => { var chart = echarts.init(document.getElementById('radar')); chart.setOption({ radar: { indicator: data.dimensions.map(d => ({ name: d.name, max: 100 })) }, series: [{ type: 'radar', data: [{ value: data.scores }] }] }); });

参数说明：

• indicator 的 max 必须按问卷实际最大分设置，如果维度满分只有 24，max 却写成 100，雷达图会被压成一个小圆饼，视觉效果很差；
• 前端只负责展示，计算口径必须后端统一，避免出现本地调试正确、部署后数据对不上的情况。

6.3 重复提交幂等：先查再写

测评提交接口在弱网环境里最容易因为重复点击产生两条一模一样的记录。低成本方案是客户端生成 requestId，后端幂等表判断：

if (idempotentMapper.exists(requestId)) { return Result.error("请勿重复提交"); } idempotentMapper.save(requestId);

逻辑说明：

• requestId 在用户开始测评时生成，提交时传给后端；
• 幂等表要定期清理，否则会无限增长，简单做法是每天定时删除三天前的记录。

从那以后，我每次拿到一套测评源码，都强制先花十分钟核对表结构和字符集，再启动看登录，最后才碰业务代码。这一步让我避开了很多诸如缓存不同步、表缺字段、字符集乱码这类低级问题。希望这篇拆解能让你在拿到职业心理测评系统源码后少走弯路，顺着表结构、接口路径、后台统计这个顺序走一遍，遇到问题也更容易定位到具体文件和具体方法。希望帮到你。

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