1. 项目概述与核心价值1.1 这个选题解决的是什么问题大学生心理健康已经成为高校日常管理中绕不开的话题。从大一的入学普查到每学期的例行评估再到针对重点人群的定向跟踪各高校每年要处理上万份心理测评数据。传统的做法是纸质量表或者单一的在线问卷系统测评结束之后数据散落在各个班级、辅导员或者咨询中心手里既没法统一汇总也很难从数据层面做趋势分析。这个基于Java SpringBoot的大学生心理测评与分析系统本质上就是把测评—回收—建档—分析—预警这条线整个串起来。学生登录系统完成标准化量表以SCL-90、SDS、SAS等常见量表为主系统自动计算各因子得分生成个人测评报告辅导员和心理中心老师端则能看到班级、年级、全院的多维度统计结果按照预警规则筛选出需要关注的学生名单。整套流程下来心理中心的工作效率能提升一个量级数据也真正变成了可用的资产。1.2 为什么选它作为毕设项目我接触过很多学生选题时常常卡在两个极端一种是贪大求全想做企业级电商、订餐、点歌平台结果功能堆了一堆答辩时核心亮点说不清楚另一种是过于简单只做了个单表的CRUD一眼看过去就是增删改查培训班的产物。心理测评与分析系统恰好处于一个平衡点它的核心标签是业务场景清晰心理测评在高校是刚需访客、学生、导员、心理老师、管理员五种角色各有明确的权限边界需求文档好写答辩时业务逻辑能自圆其说。技术栈主流且完整SpringBoot MyBatis-Plus MySQL Vue或Thymeleaf前些年流行SSM架构现在SpringBoot是主流中的主流。这套技术选型面试官认可度高挑不出毛病。有真正的研究点测评结果不是简单地存个数字而是涉及量表维度拆解、因子计分、常模对照、预警规则判断这些算法逻辑。这一层分析功能是拉开与其他毕设差距的关键。延展空间大可以做可视化报表、可以做班级对比分析、可以引入量表分类管理。哪怕答辩时评审老师想深挖你也拿得出东西。一句话总结这个项目具备中等偏上的复杂度业务有真实背景支撑技术有值得展开讲解的细节是一个性价比极高的毕设选题。1.3 系统整体功能地图先把完整的功能边界梳理出来后面每部分展开细说角色核心功能典型操作路径学生个人信息维护、修改密码、在线测评、查看测评报告登录 → 选择量表 → 逐题作答 → 提交 → 查看报告辅导员查看所带班级的学生列表、测评进度、班级统计、预警名单登录 → 班级总览 → 查看测评详情 → 关注预警名单心理咨询中心老师全院测评管理、创建测评任务、查看全院统计、编辑预警阈值、管理量表题库创建任务 → 设置参与范围 → 实时查看回收进度 → 处理预警系统管理员用户管理、角色管理、学院与班级维护、系统日志管理基础数据 → 给老师/辅导员开通账号这个功能划分是有讲究的。测评系统最忌讳的就是谁都能看所有结果——测评数据属于隐私信息所以权限模型从设计第一天就要严格区分开。这也是答辩时一个很好的加分点。2. 技术选型与架构设计拆解2.1 为什么选SpringBoot而不是SSH/SSM很多老教程还在推SSMSpring SpringMVC MyBatis甚至更老的SSHStruts2 Spring Hibernate。但2024年做毕设SpringBoot是唯一理性的选择。SpringBoot解决了SSM时代最折磨人的配置问题。SSM建一个项目要把web.xml、spring-mvc.xml、spring-mybatis.xml一处处配置好配置文件加起来几百行初学者稍微配错一个namespace就是整夜排查。SpringBoot基于自动配置和约定优于配置一个启动类加几个起步依赖项目就转起来了。但有一点要说明SpringBoot不是把SpringMVC和MyBatis丢了而是把它们包装成了更易用的形态。答辩时被问到底层原理你要能讲清楚SpringBoot的自动配置是通过EnableAutoConfiguration结合spring.factories新版本是AutoConfiguration.imports加载META-INF下各种XxxAutoConfiguration类根据classpath下的依赖决定是否注入Bean。请求处理还是走DispatcherServlet那一套完整的SpringMVC流程。数据持久化还是用MyBatis的Mapper/Provider机制MyBatis-Plus只是在此基础上做了通用CRUD和条件构造器的封装。2.2 前后端分离还是服务端渲染这个项目常见的实现方式有两种一种是经典的SpringBoot Thymeleaf模板引擎服务端渲染页面通过th:each、th:if在模板里渲染数据。优点是开发量小适合一个人完成部署时就是一个Jar包答辩演示省事。缺点是前后端耦合页面交互能力有限。另一种是前后端分离SpringBoot做纯API Vue3 Element Plus。前端工程独立通过Axios调用后端接口交互体验好很多做数据可视化图表也顺手。缺点是工程结构多了一层部署要分别处理前端打包文件和后端Jar包。我的个人建议是如果项目周期小于三周选Thymeleaf版本如果时间充裕或者想把项目作为找工作的敲门砖选前后端分离版本。两种版本本文后面讲到的算法逻辑、表结构、接口设计完全通用切换成本远没有想象中那么大。2.3 项目目录结构与分层规范后端工程目录结构按标准的分层架构来组织这是答辩时被问你的项目结构是怎样的时的标准答案com.university.psychology │ ├── config // 全局配置跨域配置、拦截器注册、MyBatis-Plus分页插件 ├── controller // 控制层接收请求、参数校验、返回Result对象 ├── service // 业务层接口定义 service.impl实现 ├── mapper // 持久层MyBatis-Plus的Mapper接口继承BaseMapper ├── domain // 实体层 │ ├── entity // 数据库表映射实体 │ ├── dto // 前端传参对象只承载参数不含业务逻辑 │ └── vo // 返回给前端的结果对象聚合多表数据 ├── common // 通用模块 │ ├── Result // 统一返回体 │ ├── ResultCode // 返回码枚举 │ ├── BusinessException // 业务异常 │ └── GlobalExceptionHandler // 全局异常处理器 ├── util // 工具类JWT工具、密码加密工具、常量枚举 └── interceptor // JWT拦截器做登录态校验和权限控制这个结构看着常规但每一条都有它的道理。把entity和vo分开是很多初学者最容易忽略的一点——直接把数据表实体返回给前端往往会把不该暴露的字段比如密码盐、敏感标记字段带出去心理测评系统里还有量表因子分、预警分数这些敏感数据用VO做字段隔离是必须养成的习惯。3. 数据库设计核心是表之间的语义关系3.1 核心表结构与设计依据系统的核心表一共八张用户表、角色表、学院表、班级表、量表表、维度表、题目表、测评记录表外加扩展的测评答案表和预警记录表。这里挑几张关键的展开说。用户表sys_user核心字段CREATE TABLE sys_user ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, username VARCHAR(50) NOT NULL COMMENT 登录名学号/工号, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, real_name VARCHAR(50) COMMENT 真实姓名, gender TINYINT DEFAULT NULL COMMENT 性别0未知 1男 2女, user_type TINYINT NOT NULL COMMENT 角色类型1学生 2辅导员 3心理中心老师 4管理员, college_id BIGINT COMMENT 所属学院ID, class_id BIGINT DEFAULT NULL COMMENT 所属班级ID学生必填, phone VARCHAR(20) DEFAULT NULL, email VARCHAR(100) DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 状态0禁用 1正常, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_college (college_id), KEY idx_class (class_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;几个设计的细节用户名直接用学号省去单独的学生信息表。很多项目会单独建一张student表再关联user表但毕设项目里这样做是叠床架屋user表加一个user_type字段区分角色就够了。学院和班级用两个独立字段冗余在user表里而不是通过关联表。因为用户和班级的关系是固定的属于关系不是多对多没必要建中间表。所有关联字段都加索引。虽然数据量小加不加索引SQL都能跑但这是专业习惯答辩时是否考虑过查询性能这个问题就能漂亮地回答。量表维度表scale_dimension是理解分析功能的关键CREATE TABLE scale_dimension ( id BIGINT NOT NULL AUTO_INCREMENT, scale_id BIGINT NOT NULL COMMENT 所属量表ID, dimension_name VARCHAR(50) NOT NULL COMMENT 维度名称如 躯体化、强迫症状、人际关系敏感, dimension_code VARCHAR(50) NOT NULL COMMENT 维度编码如 SOMATIZATION, low_score DECIMAL(5,2) COMMENT 低分段阈值, mid_low_score DECIMAL(5,2) COMMENT 中低分段阈值, mid_high_score DECIMAL(5,2) COMMENT 中高分段阈值, high_score DECIMAL(5,2) COMMENT 高分段阈值, description TEXT COMMENT 维度解释文案, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT量表维度表;这张表把每个评分区间对应的解释文案都放在数据库里而不是写死在Java代码中。好处是心理老师自己就能调整解释内容不用改代码。这是评测系统一个很重要的设计理念——把知识类内容从代码中剥离。题目表scale_questionCREATE TABLE scale_question ( id BIGINT NOT NULL AUTO_INCREMENT, scale_id BIGINT NOT NULL COMMENT 所属量表ID, dimension_id BIGINT NOT NULL COMMENT 所属维度ID, question_content VARCHAR(500) NOT NULL COMMENT 题目内容, sort_order INT DEFAULT 0 COMMENT 排序, option_count TINYINT DEFAULT 5 COMMENT 选项数量常见为5, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT量表题目表;测评记录表assessment_record记录每一次测评的原子数据CREATE TABLE assessment_record ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 测评学生ID, task_id BIGINT COMMENT 测评任务ID可为空表示自主测评, scale_id BIGINT NOT NULL COMMENT 使用的量表ID, total_score DECIMAL(5,2) COMMENT 量表总均分, positive_items INT COMMENT 阳性项目数, status TINYINT DEFAULT 1 COMMENT 0草稿 1已完成, submit_time DATETIME DEFAULT NULL COMMENT 提交时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_task (task_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT测评记录表;测评答案表assessment_answer是每一道题的原始作答CREATE TABLE assessment_answer ( id BIGINT NOT NULL AUTO_INCREMENT, record_id BIGINT NOT NULL COMMENT 测评记录ID, question_id BIGINT NOT NULL, dimension_id BIGINT NOT NULL, option_value TINYINT NOT NULL COMMENT 选项值1~5, PRIMARY KEY (id), KEY idx_record (record_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT测评答案表;把答案单独拆出来而不是塞进record是因为分析时要按维度聚合计算——单独成表一条SQL就能把某次测评各维度的均分都算出来结构清爽。3.2 测评任务表设计让组织测评成为可管控的流程整套系统里最有业务价值的一张表是测评任务表。它有产品思维在里面不是简单的CRUDCREATE TABLE assessment_task ( id BIGINT NOT NULL AUTO_INCREMENT, task_name VARCHAR(100) NOT NULL COMMENT 任务名称如 2024秋季学期心理健康普查, scale_id BIGINT NOT NULL COMMENT 使用的量表, target_type TINYINT NOT NULL COMMENT 发布对象1全体学生 2指定学院 3指定班级, target_ids VARCHAR(500) COMMENT 学院ID或班级ID集合逗号分隔, start_time DATETIME NOT NULL COMMENT 开始时间, end_time DATETIME NOT NULL COMMENT 截止时间, status TINYINT DEFAULT 0 COMMENT 0未开始 1进行中 2已结束 3已归档, create_by BIGINT NOT NULL COMMENT 创建人心理中心老师, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT测评任务表;很多初级开发者做测评系统只会做学生点开量表开始答题完全没有任务这个概念。但实际业务中心理中心每学期都要组织一次全院普查普查是有时间范围、有对象范围的。任务表的引入让组织一次测评从系统操作层面完整闭环了老师创建任务选定量表和对象设置起止时间。到开始时间后范围内学生登录系统会看到待办任务。提交后任务状态自动更新老师端实时看到回收率。任务结束后系统自动归档生成全院报告。答辩时如果能主动讲清楚我为什么要设计任务表而不仅仅是量表自助测评评审老师的印象分会明显不一样。4. 测评算法与心理分析核心实现4.1 SCL-90量表维度计算逻辑系统的核心算法是维度计分。以最常用的SCL-90症状自评量表为例它包含90道题分为9个因子维度。每个维度包含的题目数不一样比如躯体化维度有12题强迫症状有10题人际关系敏感有9题。计分方式为因子分 该维度所有题目得分之和 / 该维度题目数也就是维度均分。对应到代码层面提交测评时Service层处理流程如下Override Transactional(rollbackFor Exception.class) public AssessmentResult submitAssessment(SubmitAssessmentDTO dto) { // 1. 参数校验判断测评任务是否在有效期内 AssessmentTask task validateTask(dto.getTaskId()); // 2. 获取该量表的全部题目 ListScaleQuestion questions questionMapper.selectList( new LambdaQueryWrapperScaleQuestion() .eq(ScaleQuestion::getScaleId, dto.getScaleId()) .orderByAsc(ScaleQuestion::getSortOrder)); // 3. 保存答案明细 ListAssessmentAnswer answers buildAnswers(dto.getAnswers(), questions); answerMapper.batchInsert(answers); // 4. 按维度分组汇聚计算因子分 MapLong, DimensionScore dimensionScoreMap calculateDimensionScores(answers); // 5. 根据维度分计算总均分与阳性项目数 BigDecimal totalAvg calculateTotalAverage(dimensionScoreMap); int positiveItems countPositiveItems(dto.getAnswers()); // 6. 生成测评记录 AssessmentRecord record buildRecord(dto, totalAvg, positiveItems); recordMapper.insert(record); // 7. 遍历各维度匹配异常阈值生成预警记录 generateWarningRecords(record, dimensionScoreMap); // 8. 构造返回VO包含每个维度的得分、解释文案、综合建议 return buildResultVO(record, dimensionScoreMap); }核心是第四步calculateDimensionScoresprivate MapLong, DimensionScore calculateDimensionScores(ListAssessmentAnswer answers) { MapLong, ListInteger dimensionScoreMap new HashMap(); for (AssessmentAnswer answer : answers) { dimensionScoreMap .computeIfAbsent(answer.getDimensionId(), k - new ArrayList()) .add(answer.getOptionValue()); } MapLong, DimensionScore result new HashMap(); dimensionScoreMap.forEach((dimensionId, scoreList) - { double sum scoreList.stream().mapToInt(Integer::intValue).sum(); double avg sum / scoreList.size(); // 保留两位小数 double avgRounded Math.round(avg * 100.0) / 100.0; result.put(dimensionId, new DimensionScore(dimensionId, avgRounded)); }); return result; }为什么维度分取均分而不是总分因为不同维度题目数不同总分不可比。拿躯体化12题和恐怖7题直接比总分结果偏差非常大。用了均分之后各维度之间直接可以横向比较系统才知道学生在哪个维度上偏移最明显。4.2 预警规则与分级判定预警是心理测评系统里最要命的功能它直接影响学校是否会对某个学生进行人工干预。预警逻辑用Java实现时必须做到规则明确、可配置、可追溯。我在这里采用的是一套三级预警判定方案灵感来自实际心理中心的工作流程预警级别判定条件处置建议一级高度关注总均分 3且任一因子分 3.5建议24小时内安排专人访谈二级重点关注总均分 2.5 且 3或任一因子分 3建议一周内安排访谈持续观察三级一般关注总均分 2 且 2.5或阳性项目数 40建议日常关注定期回访正常不满足上述条件无这个阈值并不是拍脑袋定的。SCL-90常模中因子分超过2通常被认为可能存在轻度症状超过3是明显症状总均分超过2.5已经是需要重点关注的水平。实际开发中我还会把阈值配置化放到数据库里心理中心老师自己就能结合实际调整。预警处理还要注意一个坑同一个人多次扫测的预警记录要合并防止重复打扰。比如某个学生2023年秋季和2024年春季都被预警系统里应该按学生聚合显示历史预警轨迹而不是每学期一条孤立记录。我开发时用了一个视图来聚合学生最新的预警级别和历史预警次数。4.3 测评报告中的解释文案生成系统生成的报告长什么样直接决定了这个项目演示效果的下限。报告不是简单把分数列出来而是要输出一段让非专业人士也能读懂的描述。我采用的方案是将维度解释文案维护在数据库维度表中再按得分区间 变化趋势拼接出报告段落。private String generateDimensionSummary(DimensionScore score, Dimension dim) { String levelDesc; if (score.getAvgScore() dim.getHighScore()) { levelDesc dim.getHighDesc(); // 显著高于常模 } else if (score.getAvgScore() dim.getMidHighScore()) { levelDesc dim.getMidHighDesc(); } else if (score.getAvgScore() dim.getMidLowScore()) { levelDesc dim.getMidLowDesc(); } else { levelDesc dim.getLowDesc(); } // 输出躯体化因子得分1.92处于正常范围提示近期无明显躯体不适主诉... return String.format(%s因子得分%s%s, dim.getDimensionName(), score.getAvgScore(), levelDesc); }这一层文案极大提升了项目的分析感——学生看到的不是冰冷的数字而是有温度的文字描述。答辩演示时这一屏内容包含大量个性化措辞一看就不是简简单单的增删改查。5. 关键功能模块前端交互与后端联动5.1 在线测评过程的细节处理在线测评看起来简单——展示题目、收集答案、提交。但实训中我踩过很多坑坑一误触提交。90道题的SCL-90量表答到第80题时误触刷新或者误点提交前面的80题全丢学生心态直接崩掉。我的解决方案是前端监听beforeunload事件刷新或关闭页面时弹窗确认。答题过程采用本地暂存机制每隔10道题将已答内容存入localStorage一旦异常刷新可以恢复。提交时二次确认弹窗明确提示提交后不可修改。坑二答题状态的实时保存。后端接口设计上我额外提供了一个saveDraft接口学生可以保存草稿后退出下次登录继续答。对应数据库record表的status字段从0草稿改成1已完成。这个功能真实心理中心很需要——有些学生就是没法一次性90分钟答完。坑三限时控制。服务端要在提交时校验记录创建时间和当前时间超过预设时限比如120分钟要拒绝提交或者做标记。特别注意不能只靠前端限制时间前端的时间限制分分钟可以被绕过后端校验才是底线。5.2 数据可视化让统计结果一眼看懂做心理测评系统有一个隐藏加分项——数据可视化。学生端报告页、老师端全校统计页如果只摆表格效果打折一半。前端我推荐用ECharts后端接口配合返回聚合数据。三个可视化图表的实现我评估下来性价比最高第一张各维度因子分雷达图。学生个人报告用雷达图展示9个维度得分红色区域代表超过常模阈值的部分。这种图对维度间的对比非常直观学生和老师一眼就能看出哪个维度突出。第二张全院预警等级分布饼图。老师端看全院学生预警等级占比正常/三级/二级/一级。本质上是按预警级别分组计数后端SQL按level分组count即可。第三张各学院测评完成率趋势图。测评任务进行中老师端最关心的就是各班完成进度。前端轮询接口每5分钟刷新一次罗列各班级未测人数/总人数的进度条。这个功能在各学院之间还能形成隐性的追赶效应实际使用中非常有效。后端折线图接口返回的数据结构public class TaskStatisticVO { private Long taskId; private ListCollegeProgressVO collegeProgress; // 每日提交人数趋势 private ListDailySubmitVO dailySubmitTrend; } public class CollegeProgressVO { private Long collegeId; private String collegeName; private Integer totalStudents; // 应测人数 private Integer submittedCount; // 已测人数 private BigDecimal completionRate; // 完成率保留百分比两位小数 }5.3 JWT登录认证与权限控制测评系统涉及敏感数据登录认证不能随便用Session糊弄。我用的是JWTJSON Web Token方案Service public class AuthService { public String login(String username, String rawPassword) { SysUser user userMapper.selectByUsername(username); if (user null || !BCrypt.checkpw(rawPassword, user.getPassword())) { throw new BusinessException(ResultCode.LOGIN_ERROR, 用户名或密码错误); } if (user.getStatus() 0) { throw new BusinessException(ResultCode.ACCOUNT_DISABLED, 账号已被禁用); } // 生成JWT包含用户ID、用户类型有效期两小时 MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(userType, user.getUserType()); return JwtUtil.generateToken(claims); } }JWT的好处是服务端无状态配合拦截器做统一鉴权非常轻便。配置一个拦截器注册Override public void addInterceptors(InterceptorRegistry registry) { // 学生端测评接口需要登录 registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/register); // 辅导员和心理中心接口需要特定角色 registry.addInterceptor(new RoleInterceptor()) .addPathPatterns(/api/teacher/**, /api/center/**) .excludePathPatterns(/api/auth/login); }密码加密用BCrypt而不用MD5这个细节答辩时被问到的话要讲清楚MD5本身存在碰撞和彩虹表风险而BCrypt内置随机盐、计算成本可调是目前存储密码的标准做法。5.4 自助测评与强制测评双模式系统实际运行中会遇到两种测评场景普查型强制心理中心下发的任务学生登录后系统通过待办列表提示您有一项心理健康测评待完成不完成的话在首页持续展示。自助型自愿学生自己有了解心理状况的意愿主动从量表列表选择一个开始测评。这类测评结果默认只对本人和咨询中心可见不会推送给辅导员。这两种模式后端要做的区分是任务关联的测评记录会进入班级完成度统计自助测评不计入同时自助测评的预警记录可见范围更小默认只有心理中心老师能看到。数据权限在查询层就要过滤好而不是等前端做展示判断。6. 测评任务与报表统计的实现要点6.1 教师端任务配置核心逻辑创建测评任务时有个细节做得不好非常容易被答辩老师追问发布对象的选择。任务的目标人群可能是全体学生、某几个学院的学生、某几个班级的学生。前端用三个tab切换范围选择后端对应设计如下public void createTask(CreateTaskDTO dto) { // 根据targetType处理targetIds ListLong targetIds dto.getTargetIds(); if (dto.getTargetType() TARGET_ALL) { // 全体学生不需要具体ID集合 assessmentTask.setTargetIds(); } else if (dto.getTargetType() TARGET_COLLEGE) { // 按学院存学院ID集合 assessmentTask.setTargetIds(StringUtils.join(targetIds, ,)); } else if (dto.getTargetType() TARGET_CLASS) { // 按班级存班级ID集合 assessmentTask.setTargetIds(StringUtils.join(targetIds, ,)); } assessmentTaskMapper.insert(assessmentTask); }任务创建之后有一个学生端待办任务如何生成的问题。最直白的方案是任务创建时把范围内所有学生批量插入一张task_user关联表。但高校动辄几万学生每次普查都要生成大量关联记录损耗较大。我的替代方案是不做物理生成做逻辑查询——学生端查待办任务时直接按任务的条件动态过滤用户表// 学生端待办查询伪代码 public ListTaskVO getMyTodoTasks(Long studentId, Long collegeId, Long classId) { ListAssessmentTask allTasks taskMapper.selectRunning(); ListTaskVO result new ArrayList(); for (AssessmentTask task : allTasks) { if (taskContainsStudent(task, collegeId, classId)) { // 判断该学生是否已经提交 long count recordMapper.selectCount( new LambdaQueryWrapperAssessmentRecord() .eq(AssessmentRecord::getTaskId, task.getId()) .eq(AssessmentRecord::getUserId, studentId)); if (count 0) { result.add(taskVO); } } } return result; }数据量少时这样动态过滤性能没有问题逻辑也简单能避免一致性维护问题。如果你的数据量真的到了几万再考虑用异步任务生成中间表道理是一样的。6.2 完成率统计的SQL编写技巧测评任务中途心理中心老师要实时看完成率。最核心的一条统计SQL是各班应测人数 vs 已测人数SELECT c.id AS class_id, c.class_name, COUNT(u.id) AS total_students, COUNT(DISTINCT CASE WHEN r.id IS NOT NULL THEN u.id END) AS submitted_students FROM sys_user u INNER JOIN sys_class c ON u.class_id c.id AND u.user_type 1 LEFT JOIN assessment_record r ON r.user_id u.id AND r.task_id #{taskId} AND r.status 1 WHERE u.status 1 GROUP BY c.id, c.class_name ORDER BY submitted_students DESC;注意这里LEFT JOIN时的关联条件把task_id限定放到了ON子句里而不是WHERE子句里。放在WHERE里会把没有测评记录的学生过滤掉统计就错了。这个细节是SQL join的经典坑。6.3 历史趋势分析与年度对比如果想让项目分析两个字更加名副其实可以加一个历史趋势模块按学期维度统计全院总分均值和预警率。实现方式简单但很有说服力给测评记录表加上semester字段如2024-2025-1统计接口按学期分组聚合public ListTrendVO getTrendData() { // 折线图横轴学期纵轴预警率/平均总均分 return assessmentRecordMapper.selectTrendBySemester(); }对应SQL用GROUP BY semester配合AVG、SUM聚合即可。这个功能做出来后系统就从测试工具升级成了辅助决策工具答辩时拿出这张趋势图说心理中心可以借助它观察学生心理健康水平的年度变化档次完全不一样。7. 常见问题排查与调试实录7.1 统计数字对不上的排查思路排查统计类问题最常用的办法就是拆解成单条SQL手动执行比对数据。如果班级应测人数比实际人数少按优先级排查是不是user表的class_id为空导致副班级的学生没有关联上解决检查数据初始化脚本时班级ID的维护。是不是user_type不是1把管理员和辅导员统计进来了解决统计时强制where user_type1。是不是LEFT JOIN的关联条件少了任务ID过滤导致所有历史测评都算作已测解决把task_id条件移到ON子句中只统计当前任务。实际部署时最常见的还真的是条件放错位置以及重复测评没有去重。一个学生因为答到一半退出又重做产生了多条record记录导致完成人数大于应测人数。防御方案是对user_id task_id加唯一索引第二次提交直接提示已提交。7.2 MyBatis-Plus分页失效的经典问题分页是每个系统都要用到的功能但初学者几乎都会踩这个坑。使用MyBatis-Plus分页光引入分页插件还不够必须显式配置Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }不配这段代码分页查询不生效Page对象会查出全表数据。更隐蔽的问题是自定义SQL中如果使用了JOIN且实体对应多表字段分页插件在COUNT语句拼接时可能报错。遇到这种情况改用Select注解手写count查询或者关闭自动count、自己提供count方法。7.3 时间字段的时区与格式化陷阱测评任务的时间判断逻辑是当前时间是否在startTime和endTime之间。如果数据库时区和服务端时区不一致会出现任务已结束但学生还能提交的诡异问题。我的处理方案是数据库连接串加参数serverTimezoneAsia/Shanghai。任务时间统一用DATETIME类型不存时间戳避免各种时区换算。判断用Java 8的LocalDateTime.now()与服务端当前时间对比而不是依赖数据库的NOW()。public void validateTask(AssessmentTask task, LocalDateTime now) { if (now.isBefore(task.getStartTime())) { throw new BusinessException(测评任务尚未开始); } if (now.isAfter(task.getEndTime())) { throw new BusinessException(测评任务已截止); } }7.4 前端与后端跨域配置前后端分离开发时前端工程跑在8080端口后端跑在8888端口浏览器会拦截跨域请求。SpringBoot侧全局配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:8080) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意若使用了JWT拦截器预检请求OPTIONS要在拦截器层面直接放行否则浏览器跨域预检失败前端会看到跨域请求被阻止的经典报错。7.5 常见问题速查表症状原因解决方案登录后访问接口返回401JWT过期或token未携带拦截器配置放行登录接口前端请求头携带Authorization测评提交后报告分数全为0答案数组和题目ID没有正确关联检查前端提交格式后端逐个校验questionId任务创建后学生看不到待办任务状态不是进行中或时间范围不包含当前时间检查任务状态流转逻辑确认在前端发布后状态置为进行中预警名单数据为空预警判定阈值设置过高或维度分计算错误用已知数据反推分数打印每个因子的原始得分和题目数前端静态资源404前后端分离部署路径未配置后端配置静态资源映射到dist目录或使用Nginx托管前端8. 开发调试与部署运行经验8.1 基于Docker的本地开发环境搭建推荐用Docker Compose把MySQL和Redis一拉起减少环境配置杂事。一个简单的docker-compose.ymlversion: 3.8 services: mysql: image: mysql:8.0 container_name: psych-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: psych_system TZ: Asia/Shanghai ports: - 3306:3306 volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql command: --character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci用./init.sql挂载作为初始化脚本数据库表结构和初始数据第一次启动时自动导入省去手动执行的步骤。记得在application.yml里配置对应的数据源。8.2 初始化数据的艺术量表数据从哪来项目中最大的初始数据工作量不是用户数据而是SCL-90的90道题目和9个维度。市面上各大高校心理中心用的量表题目和计分规则不完全一致但SCL-90作为公开的标准化量表题目内容是可以公开获取的。为了保证演示效果初始化脚本至少要导入1套完整SCL-90量表90题9维度。1套SDS抑郁自评量表20题。1套SAS焦虑自评量表20题。3~5名模拟学生账号附带测评结果数据目的是让老师端的统计图表一开始就有数据可看不至于演示时空空荡荡。模拟测评数据用SQL批量造一个学生4个学期各2次测评数据有一定的分散性既有高分预警也有正常这样图表展示效果最有说服力。这个细节做项目的一定要提前准备往往决定了答辩演示的流畅度。8.3 打包部署与演示环境准备后端用Maven打包mvn clean package -DskipTests java -jar target/psych-system.jar前端如果是Vue工程执行npm run build后把dist目录放到Nginx下反向代理/api到后端端口server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }答辩现场最忌讳的是环境问题翻车。我建议准备双保险主力用本地浏览器访问同时手机开热点给备用电脑远程访问部署好的服务器版本。无论哪边出问题都能无缝切换。9. 答辩与演示经验总结9.1 演示顺序的设计思路系统演示环节不要平铺直叙从登录开始而是带着问题演示。我建议按发现者→关注者→管理者的视角逻辑来串先以学生身份登录完成一次测评跳转报告页展示雷达图和文字解读。切换辅导员账号看到班级列表、测评进度和预警名单。切换心理中心老师账号展示全院统计、班级完成率、趋势分析、预警处理。最后展示管理员页面说明用户、角色、权限的整体设计。这样演示完成了一条完整的业务链评审老师跟着你的思路走不会有这不就是个CRUD的感觉。9.2 答辩时容易被追问的高频问题提前把这些问题想清楚回答时有条理拿高分的概率会大很多为什么选SCL-90作为默认量表——标准化公开量表信效度有依据9维度结构清晰行业通用。预警的阈值依据是什么——结合量表常模3为明显症状的行业通用标准实训时参照心理中心老师的意见做了分级调整。如何保证测评数据的真实性和有效性——防作弊思路主要有四点限时提交、题型乱序、前后测一致性校验、异常作答标记例如全选同一选项。系统的安全和隐私如何考虑——密码BCrypt加密、JWT鉴权、敏感数据按角色隔离、导出报告权限控制。这个系统如果上线实际业务中还缺什么——缺与学校现有教务系统对接学生数据、消息通知触达、历史档案跨系统共享。这里主动暴露不足反而展示思考深度。9.3 项目进一步扩展的三个方向如果时间和精力允许以下三个方向对项目层次提升非常明显引入更多量表及维度配置化当前系统已经做到维度表的配置化可以进一步做整体的量表管理页面让非技术人员自助上传量表。一般做到这里系统已经是平台级的雏形了。增加AI辅助分析模块基于历史测评数据和预警记录简单套用规则引擎或统计模型给出测评报告的文字自诊建议模块是较为务实的扩展点。移动端适配问卷答题核心场景在手机上。如果前端是Vue工程可以在此基础上做PWA或者响应式布局适配把测评体验搬进移动端。这个方向不是随意发散而是符合心理中心大规模普查真实业务场景的刚需每个扩展都能讲出明确的业务价值。说实话这个项目我从一开始规划到最后打包上线前后花了三周左右的业余时间。最有价值的收获不是那一堆CRUD代码而是在设计任务—测评—维度—预警—分析这条链路时真正把心理测评这个行业业务吃透了。做完之后再去看市面上的同类系统能一眼看出它们功能设计上的问题。这种业务理解能力才是毕业设计真正想锻炼的东西。如果你正在做类似的系统希望这篇帖子能帮你少走几个弯路。