Spring Boot校园心理服务系统毕设全流程开发指南

毕设选题年年都有新花样，但“Spring Boot校园心理服务系统”这个题目，这几年算是常青树了。它不光是搭个网页交差那么简单，背后其实覆盖了用户体系、预约流程、测评逻辑、内容管理、数据统计等一系列完整闭环。不管你是正在纠结选题方向，还是已经定题准备开写，这篇文章都会把整个项目的设计思路、核心模块、关键表结构和实测踩坑记录全部摊开给你看，直接当参考模板用。

1. 项目概述与需求拆解：选题为什么火，系统到底在解决什么问题

1.1 选题价值与背景分析

最近几年高校对心理健康服务的重视度明显在上升，但现实中“想做咨询但不知道怎么约”“心理中心排班靠人工登记”“测评结果散落在纸质问卷里”这些问题，几乎是每所学校的通病。于是“校园心理服务系统”就成了一个既有社会意义、又有真实业务场景的毕业设计选题。从答辩角度讲，这类题目有明确的服务对象（学生、咨询师、管理员），有清晰的角色权限划分，也有一连串可以演示的完整业务流程，比那种纯CRUD的“XX管理系统”要好讲得多。

选Spring Boot作为技术栈，是当前最稳妥的选择之一。Java生态在高校课程里覆盖面广，Spring Boot本身又降低了配置成本，内置Tomcat一键启动，配合Vue做前后端分离，整套技术链既符合教学体系内学的东西，又能往简历上写“前后端分离项目经验”，性价比非常高。

1.2 核心需求与角色细分

把一个“心理健康服务”的标题翻译成具体功能，我会先把用户拆成三种角色来看。

• 学生端：浏览心理科普文章、在线做心理测评量表、查看测评结果与建议、发起咨询预约、查看预约状态、填写咨询后的反馈评价。
• 咨询师端：维护个人可预约时段、处理待确认的预约、填写咨询记录与摘要、回复学生的留言反馈。
• 管理员端：审核并发布心理文章与资讯、管理系统用户（如禁用异常账号）、维护测评量表题库及各维度计分规则、查看系统整体预约流量与测评统计报表。

事实上很多初学者拿到这个题目后，容易把系统做成“一个简单的文章展示+在线留言板”，但那样确实撑不起一个合格的毕业设计深度。真正拉开档次的分水岭在于两块：一是“测评”不是简单选完题出个总分，而是必须按量表维度来计算，并给出对应的解释文本；二是“预约”不是随便存一条记录，而是要考虑时段冲突、咨询师日程匹配、状态流转（待确认/已完成/已取消）这些业务规则。

1.3 系统建设目标与技术指标

在动手前要明确这个系统最终要达成几种能力：

1. 支持学生、咨询师、管理员三类账号的统一认证登录，且不同角色登录后看到的是完全不同的功能面板。
2. 测评模块支持多套量表（比如SDS抑郁自评量表、SAS焦虑自评量表这类通用程度高的），每套量表有独立的题目、选项分值、维度分组和结果区间解释。
3. 预约模块基于咨询师的周排班生成可选时段，学生预约后状态实时更新，避免出现多名学生同时约到同一个咨询师同一时段的情况。
4. 管理员端至少能看到“各量表测评人数趋势”和“各咨询师预约量对比”，用图表方式展示，这部分和ECharts整合起来也很加分。
5. 系统内所有涉及用户敏感信息的数据（如测评结果、咨询记录）在数据库存储层面考虑加密或字段分级管理，至少要在设计文档里把隐私保护思路讲清楚。

2. 技术选型与系统架构：为什么这么搭，前后端怎么分工

2.1 后端技术栈

Spring Boot版本建议直接用2.7.x，别去碰最新的3.x。原因很简单，国内大多数教学资源和网上找到的参考代码都基于2.x，你做到一半遇到问题时，靠搜索能找到大量现成答案；而3.x的依赖命名、Jakarta命名空间和部分配置方式变了，一旦卡住排查成本很高。为了让你心里有个底，我把核心依赖整理成了一张表。

我实话实说，对于很多学生来说，Spring Security那一套过滤器链、认证管理器、密码加密的配置，光是自己调通就得折腾好几天。如果项目主打功能是业务流程的完整度而不是安全框架的深度，用Sa-Token是非常明智的选择。Sa-Token的登录认证用几行代码就能拿到当前登录用户，还内置了权限校验注解，搞完登录鉴权再去做业务功能，心情会好不少。

2.2 前端技术方案

前端可以选Vue 2或Vue 3。如果选修课教的是Vue 2，那就用Vue 2 + Element UI，别盲目追新，毕竟你只有几个月时间，不是去参加前端框架选型大会；如果自己有点基础，直接Vue 3 + Vite + Element Plus会更现代，过程也顺。

独立的前端工程需要解决的技术细节不算少，但每一个都有成熟的解决办法：

• HTTP请求封装，用Axios拦截器统一携带token，后端返回401时自动跳转登录页。
• 路由守卫，未登录的用户访问任何业务页面都强制跳回登录页。
• 不同角色的菜单动态渲染，登录成功后从后端拿当前用户的权限标识，前端按角色生成路由与侧边栏菜单。
• 打包部署时前端工程npm run build生成dist目录，可以交给Nginx托管，也可以直接把dist目录里的静态资源扔进后端resources/static下，实现单工程启动同时访问接口和页面。

2.3 系统整体架构分层

在做项目的时候，不管后端模块写多少，代码结构建议每层各司其职。

code复制com.campus.psy
├── controller   // 接口层，只做参数接收和结果封装，不写业务逻辑
├── service      // 业务逻辑层，接口+实现类
├── mapper       // MyBatis-Plus的Mapper接口
├── entity       // 数据库表映射实体类
├── dto          // 前端传入参数对象，比如分页查询条件
├── vo           // 返回给前端的数据对象，比如测评结果VO
├── config       // 全局配置（跨域、拦截器、Knife4j等）
├── common       // 统一返回结果、异常处理、常量字典
└── utils        // 工具类（如JWT工具、日期工具）

分层的核心目的就是为了让项目的逻辑不乱套：controller只负责“接客”，service只负责“算账”，mapper只负责“取数”。如果controller里直接写了SQL级别的操作，那传到导师那里很可能第一眼就被打回来要求重构。

整个前后的数据交互统一走JSON，后端封装一个Result对象（包含code、message、data三个字段），比如code为200表示成功，401表示未登录，500表示业务或系统异常。简单来说，就是定义一套“接口语言”，前后端都按这套语言沟通，逻辑会清晰很多。

3. 功能模块设计与实现方式：把“测评”“预约”做出业务深度

3.1 系统功能总体拆分

当你对接下这个项目的“骨架”有一定认识之后，就可以开始拆具体模块了。核心业务可以拆成六大块来写：

1. 用户认证模块：登录、注册（注册后默认学生角色）、退出、密码加密存储、登录状态拦截。
2. 心理文章模块：管理员管理文章分类、发布文章、设置封面与是否置顶；学生按分类查看文章，支持关键词搜索。
3. 心理测评模块：学生查看可用量表 → 在线答题 → 提交后系统计算各维度得分并给出结果解释 → 测评历史可查。
4. 咨询预约模块：咨询师维护“可预约时段模板”→ 系统生成具体日期时段 → 学生选择预约并填写情况简述 → 咨询师确认或拒绝 → 咨询完成后学生可评价。
5. 留言反馈模块：学生可留言提问，咨询师进行回复，管理员可查看所有记录。
6. 统计分析模块：管理员可视化查看测评人数、用量表分类统计、咨询师服务量排行、每日预约趋势等。

这六个模块既有相对独立的管理逻辑，又有交叉的关联关系（例如学生在进行测评后可以得到推荐建议，建议内容可能会引导其去预约咨询），这样整体的业务流程就形成了一个较完整的闭环。

3.2 心理测评模块的核心规则设计

心理测评模块是整个系统中最体现业务理解深度的部分。我举一个很实际的例子：比如使用SDS（抑郁自评量表），量表本身有20个条目，每个条目按1-4级评分，其中一部分题目是正向计分，一部分是反向计分（比如“我觉得一天中早晨最好”这类积极表述条目就要反向处理）。如果直接把所有题目的得分加总，不考虑反向计分，最终结果就完全错了。

所以数据库表结构里我需要为“题目选项”单独设计两张表：一张存量表基本信息，一张存每一道题目以及对应的选项分值，再通过scale_code字段把普通测评和量表版本区分开。当学生提交测评时，后端逐题读取选项分值，同时根据题目的reverse_flag来决定最终得分的计算方向。得到粗分后，乘以1.25取整数部分得到标准分，再与标准常模临界值做比较，判断为正常、轻度、中度或重度，再给出对应的文字建议。

评分完了，光显示一个结果是不够的。更完善的做法是生成一份“测评报告”，包括总粗分、标准分、每个维度的得分情况、各条目得分最高的几项、结果说明、自助调节建议以及“如果需要专业帮助，建议预约咨询师”的提示链接。这一整段逻辑写清楚的话，在答辩时完全是一个独立的亮点。

3.3 咨询预约模块的状态流转设计

咨询预约几乎是校园心理服务系统里业务复杂性最高的模块。它不是“一对多”的简单关系，而是涉及三个维度：

1. 咨询师设置的是“每周可预约时段规则”。比如张三老师每周二下午和每周四上午可以接待咨询，按每周的重复规则存储，生成预约排班时避免手工逐条录入。
2. 管理员或咨询师在后台按周/按日“生成排班表”，把“可用时段模板”实例化成某天某时段的可约记录（例如2025-06-10 周二 15:00-15:50）。
3. 学生选择排班表中status为可预约的一条记录提交预约，这个记录要锁定，避免同一时刻两个学生对同一个排班提交预约。

从并发控制来说，最直观的办法是用数据库行锁或乐观锁。比如用UPDATE排班表SET status=2 WHERE id=? AND status=1，这条SQL在MySQL的事务下能保证只要更新成功则只有一个学生能抢到。Spring Boot里通过@Transactional配合这个update语句即可实现，比先用select判断再用update安全得多。

预约单一旦生成，后续是一个完整的状态机：

• 待确认：学生已提交，咨询师未处理。
• 已确认：咨询师确认接受，学生会收到通知。
• 已完成：咨询完成，此时学生才能填写反馈评价。
• 已取消：学生或咨询师取消，取消原因可选填，同时释放排班时段。

把这个状态流转图提前想通透，后面编码时根本不用慌，也知道哪些接口要写、哪些SQL要配。界面层面直接给不同状态渲染不同标签（待确认用橙色，已完成用绿色，已取消用灰色），一眼就能看明白。

3.4 后台内容管理模块

后台内容管理模块包括用户管理、文章管理、咨询师时段管理、测评记录查看等。这里有一点值得注意：测评记录属于隐私数据，学生在列表页只能看自己的记录，但管理员查看时建议做“数据脱敏展示”，比如查看学生姓名时可以缩写为“张同学”或者“李**”，毕竟为了演示安全合规的细节更体现综合素质。

整个后台管理界面用Vue + Element Plus搭建，表格、表单弹窗、分页是三大主要交互要素。前端拿到数据后通过分页组件展示，后端需要按当前页码和条数进行分页查询，这一块MyBatis-Plus提供的分页插件好用不少，3行配置就能完成物理分页，不用手动拼接LIMIT语句。

4. 数据库设计：核心表结构与关键字段设计详解

4.1 ER图与核心表清单

数据库设计的成败直接决定了系统能不能支撑上面的业务逻辑。我下面给出一个简洁但够用的表清单，供你做详细设计时参照。

这是一份“够用但不臃肿”的参考设计。不少同学做系统时容易犯毛病，动不动给每个表都加十个备用字段，其实没必要。字段能按实际业务建模就好，像“是否删除”这种逻辑删除字段可以统一留到实体父类里，不必每张表单独定义。

4.2 用户表与咨询师扩展表的设计思考

用户表是系统内所有角色共同的入口。Spring Boot项目中常见的错误做法是建三张表student、counselor、admin分别存三类用户，刚开始看很清晰，但一旦公共字段变更（比如需要增加一个“手机号”），三张表都要跟着改，代码也要写三套登录逻辑。实际开发中我更推荐采用一张系统用户主表 + 扩展表的模式，主表只存与身份认证相关的必要字段，如果咨询师有特有的自我描述、接案类型等字段则放到t_counselor_profile表中，业务上需要时再关联查询。

提到密码存储，我要特别提醒一名做毕设的同学，千万别把密码明文存在数据库里，一次项目答辩可能老师就会直接对你的数据库翻看密码字段。一般处理是使用BCrypt或者Spring Security自带的PasswordEncoder进行加盐哈希存储。即使用户表中的密码字段被人拖走，也无法反推出原文，这在心理服务这类涉及隐私场景的系统中尤其重要。

用户表在设计上要考虑角色字段，用一个字符串来标记，比如ROLE_STUDENT、ROLE_COUNSELOR、ROLE_ADMIN，后端在拦截器里按角色判断接口访问权限即可。

4.3 测评核心表设计细节

测评模块的扩展性很重要，因为不确定后期是否需要增加新量表。把“量表-题目-选项”采用垂直拆分设计，换句话理解就是拿空间换扩展性。

比如量表里每道题的存储格式大概是：

• id：题号
• scale_code：标记属于哪个量表，如“SDS”
• question_text：题干
• sort_order：排序号
• reverse_flag：0正向计分、1反向计分

同时还需要为量表设计一个“维度表”吗？一般SDS是单维度量表，但像SCL-90这类症状自评量表则包含躯体化、强迫症状、人际关系敏感等九个维度，属于多维度量表。如果为了通用性，设计难度会增加不少；如果只是做毕业设计，则可优先选择一到三个单维度量表，再加上两个简单多维量表，然后对“多维度结果展示”用JSON字符串或者在结果表中设计维度得分字段处理即可。过度设计同样会拖垮开发进度。

一个直接可用的方案是：t_scale表维护scale_code和scale_name，t_scale_question表中增加dimension_name字段，每个题目归属某个维度，计算时按维度名动态分组统计。这样再增加量表时只需要往库里导入题目。

4.4 预约相关表的时间处理

时间字段处理是预约系统最大的坑之一。排班模板表里存的是星期几和开始、结束时分，比如tuesdayFlag表示周二可用。但到了具体某一天，系统要根据“本周二”去生成一条实际排班记录，例如2025-06-10 15:00-15:50。到了这一步，模板的起始逻辑和按日历生成逻辑就要分开建模。

更好的方案是模板只做一次性“生成”动作，把模板在前端勾选好之后，点“生成本周排班”，系统扫描所选日期范围内每一天，匹配星期规则，并插入当天的可约时段数据。后续若要调整某一天可用性，直接调整t_schedule表里该行的状态，模板保留不动以便下周重新生成，人工特殊处理也不会被模板覆盖。

关于日期和时间实用工具，我推荐直接用Hutool的DateUtil和DateTime，计算某天是星期几，生成某一天内一段时间序列，这些功能大约5行代码就可以解决，不需要自己手写Calendar换算，少踩坑也少掉头发。

5. 关键功能代码实现细节：把核心流程落地为可运行的后端代码

5.1 统一返回结果与全局异常处理

后端接口无论成功还是失败，建议都返回统一的结构。定义Result类如下，作为所有Controller方法的返回类型：

java复制@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(Integer code, String message) {
        Result<T> result = new Result<>();
        result.setCode(code);
        result.setMessage(message);
        return result;
    }
}

全局异常处理我一般建一个GlobalExceptionHandler类，用来兜底业务中抛出的自定义异常（比如“该时段已被预约”）。定义异常码时需要一套规则，如业务异常从1开头还是从500开头，自己要约定清楚，不然前后端联调时难以定位。在全局异常处理器里捕获异常后，把错误信息封装为Result返回前端，同时把异常日志打印出来便于排查。

5.2 使用Sa-Token实现登录鉴权

如果使用Sa-Token，登录逻辑会极度简化。以用户密码登录为例：

java复制@PostMapping("/login")
public Result<Map<String, Object>> login(@RequestBody @Valid LoginDTO dto) {
    // 1. 校验验证码（如果有）
    // 2. 根据用户名查找用户
    LambdaQueryWrapper<User> wrapper = Wrappers.lambdaQuery(User.class)
            .eq(User::getUsername, dto.getUsername());
    User user = userMapper.selectOne(wrapper);
    if (user == null) {
        throw new BizException("用户不存在");
    }
    // 3. 校验密码（BCrypt匹配）
    if (!BCryptUtil.checkPassword(dto.getPassword(), user.getPassword())) {
        throw new BizException("密码错误");
    }
    // 4. 登录，签发token
    StpUtil.login(user.getId());
    // 5. 返回前端需要的信息
    Map<String, Object> data = new HashMap<>();
    data.put("token", StpUtil.getTokenValue());
    data.put("userInfo", user);
    return Result.success(data);
}

使用Sa-Token之后，拦截器的配置也可以简化。只需要在Spring MVC配置类中注册SaInterceptor，并定义需要排除的匿名访问路径，例如/login、/register、/api/article/list等。剩下的业务接口默认全部要带token才能访问，未经登录的请求直接返回401。

5.3 测评提交接口的实现逻辑（重点难点）

测评提交接口在整个项目中是非常关键的一笔，下面给出一个核心思路伪代码，确保你能理解它背后的逻辑。

当学生请求接口POST /api/assessment/submit，传入参数包括scaleCode、量表作答的JSON数组（每个题目ID+选项ID），Service层处理步骤拆成这几步：

1. 根据scaleCode查出该量表所有题目，并建立Map。
2. 遍历前端提交的answerList，组装每题的得分：
   • 正向题则score = 选项分值；
   • 反向题则score = 最大分值 + 最小分值 - 选项分值，例如SDS中1-4级，反向题得分 = 5 - 选项分值。
3. 计算该量表的rawScore总粗分，根据量表对应的换算公式（SDS的标准分 = int(粗分 × 1.25)）计算standardScore。
4. 根据standardScore的阈值区间确定结果等级，在常量池中定义各等级区间与对应解释文案。
5. 把测评记录插入t_assessment_record表，同时用循环把明细存到t_assessment_detail表。
6. 返回给前端结果VO，包含总分、等级、各维度得分（如果有多维）、个性化建议与提示文案。

测评记录在回显时，还要注意把用户的历史记录与最新一次记录整合起来，让“我的测评报告”界面完整展示。

5.4 预约创建接口的防并发处理

学生与咨询师之间预约时段，最核心的接口代码核心逻辑如下：

java复制@Transactional(rollbackFor = Exception.class)
public Long createAppointment(AppointmentCreateDTO dto) {
    // 1. 锁定排班记录，防止多人同时预约同一个时段
    Schedule schedule = scheduleMapper.selectByIdForUpdate(dto.getScheduleId());
    if (schedule == null) {
        throw new BizException("该排班时段不存在");
    }
    if (schedule.getStatus() != 0) {
        throw new BizException("该时段已被预约或已停用");
    }

    // 2. 检查学生当前是否已有冲突预约
    //    查询该学生在该时间段是否存在状态为待确认/已确认的预约
    //    如果存在，则提示“您在该时间段已有预约”

    // 3. 将排班状态改为已预约
    schedule.setStatus(1);
    scheduleMapper.updateById(schedule);

    // 4. 插入预约记录
    Appointment appointment = new Appointment();
    appointment.setStudentId(dto.getStudentId());
    appointment.setCounselorId(schedule.getCounselorId());
    appointment.setScheduleId(schedule.getId());
    appointment.setStatus(0); // 待确认
    appointment.setReason(dto.getReason());
    appointmentMapper.insert(appointment);

    // 5. 记录通知消息
    //    messageService.send(counselorId, "您有新的预约待确认");
    return appointment.getId();
}

注意selectByIdForUpdate这个动作必须在事务内执行，MySQL的InnoDB引擎会为这一行记录加上行级排他锁，同一时刻第二次提交会阻塞，直到第一次提交事务后拿到最新状态才执行，从而避免超卖。答辩时如果被问到并发问题，可以从实现原理的角度讲清楚InnoDB的行锁机制，增加项目深度。

5.5 使用ECharts实现统计报表

管理员端统计报表的实现路径是这样的：

后端Service层按日统计7天内预约总数，返回List<Map<String, Object>>，比如[{date:"2025-06-10", count:12}, {date:"2025-06-11", count:18}]；同时统计各咨询师已完成的咨询量，返回姓名数组与数值数组。

前端在Vue的mounted方法里请求这两个接口，拿到数据后分别初始化ECharts实例并setOption。需要说明的是，项目不要为了展示而堆砌太多图表，给出“预约趋势折线图”和“咨询师服务量柱状图”两个就足够了，再把测评选项的饼图加上，整体已经能很好说明系统的实用价值。

6. 部署与交付：从Window开发到云服务器部署的完整流程

6.1 本地环境搭建与配置

开发阶段建议在本地Windows/Mac环境完成，需要准备以下基础环境：

1. JDK 1.8（若追求新特性可JDK 11，但要确保各依赖兼容）。
2. Maven 3.6+，用阿里云镜像加速依赖下载。
3. MySQL 8.0本地实例，创建数据库campus_psy，字符集utf8mb4。
4. Redis（非必须，但如果用于存储验证码或Sa-Token缓存则建议安装Windows版或Docker版）。
5. Node.js 16+，用于启动Vue前端，执行npm install和npm run dev。
6. IDEA开发工具，装上Lombok插件和MyBatisX插件，后者可以快速生成Mapper方法。

Spring Boot的application.yml里面要重点注意这几个配置项：

yaml复制server:
  port: 8080
  servlet:
    context-path: /

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/campus_psy?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

sa-token:
  token-name: satoken
  timeout: 2592000
  is-concurrent: true

6.2 前后端打包与部署实践

开发完成后通常部署到一台轻量云服务器上，学生用轻量应用服务器选择2核4G就足够了。部署流程如下：

后端打包，在项目根目录执行mvn clean package -DskipTests，生成target目录下的jar包；在服务器上直接使用nohup java -jar campus-psy.jar > logs/app.log 2>&1 &启动。

前端打包，在项目前端目录执行npm run build，生成dist目录。此时有两种部署模式可选：

模式A：把dist目录下所有文件复制到后端resources/static目录，重新打包后访问服务器IP+端口即可看到系统首页，同时后端接口也能正常访问，无需额外配Nginx。

模式B：服务器上安装Nginx，把dist目录映射为Nginx的root目录，并将/api前缀的请求反向代理到localhost:8080，这种方式前后端完全分离，更接近实际企业做法。

以模式B的Nginx核心配置为例：

nginx复制server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        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;
    }
}

需要注意的前后端联调坑位：一是前端请求路径必须以/api开头统一约定；二是开发时前端通过Vite配置proxy代理到localhost:8080，避免开发环境跨域问题发生；三是ServerTimezone必须配置为Asia/Shanghai，否则存储的时间会差8小时。

6.3 答辩演示数据准备

这个环节虽然不是编码任务，但我专门提醒一句：真正到答辩前至少准备三套不同状态的演示数据，并且是看起来自然的数据，而不是随手乱填的“aaa”“bbb”。

比如预约功能演示时，你可以提前造好下面几类“剧本数据”：

• 本周已有三条预约，分别处在待确认、已完成、已取消状态，界面展示不同标签。
• 已完成的预约里面对应一条咨询记录和一条学生评价。
• 学生端测评记录列表里包含3个不同量表的测评历史，时间分别在两周前、一周前、昨天，这样按时间倒序展示时能体现数据变化。
• 某些预约已超过未确认状态多日，系统定时任务自动将其标记为“已失效”。

准备完这些数据后，答辩现场只需要顺着业务流程点几次鼠标，就能把整个系统的闭环走一遍，比你临时输入一堆“测试001”要可靠得多。

7. 常见问题与项目排查：把这块硬骨头从入门到精通的完整经验参考

7.1 环境与依赖版本问题

问题1：Spring Boot启动报错关于Jakarta命名空间，一看就知道你把Spring Boot升级到了3.x但还在用老代码逻辑。解决思路是降回2.7.x再重新mvn clean，或把javax.替换为jakarta.。对毕业设计来说我强烈建议直接降到2.7.x。

问题2：MyBatis-Plus实体字段下划线转驼峰失效。大部分问题集中在配置信息中mapUnderscoreToCamelCase没有开启。MyBatis-Plus默认自带这个转换，但需要在application.yml中不要把它关闭。

问题3：前端npm install卡了很久。一般建议使用国内镜像，在项目根目录创建.npmrc文件并写入registry=https://registry.npmmirror.com。

7.2 数据一致性常见问题

测评记录保存后，历史记录查询时发现自己总分的字段为null，这类问题多半是插入的字段名与数据库列名没有对应上。排查方式：先看日志SQL语句，再使用MyBatis-Plus的@TableField注解或者关闭驼峰映射后统一列名。

预约状态更新时，经常会有同学用updateById方法直接把整个对象更新了，结果因为没有在实体中赋值status字段，导致状态字段被覆盖成null。解决办法：使用UpdateWrapper只更新需要更新的字段：

java复制LambdaUpdateWrapper<Appointment> wrapper = Wrappers.lambdaUpdate(Appointment.class);
wrapper.eq(Appointment::getId, id)
       .eq(Appointment::getStatus, 0)   // 条件判断防并发
       .set(Appointment::getStatus, 1);
int rows = appointmentMapper.update(null, wrapper);

7.3 安全性不足常见问题

接口没有做权限控制、学生可以凭接口地址直接访问管理员接口。通常需要在后端单独建一个WebMvcConfigurer配置类，注册Sa-Token拦截器并对路径进行规则设定，例如将/admin/**设置为必须登录且必须具有管理员角色，才能访问。加上注解@SaCheckRole("admin")即可实现细粒度权限控制。

对心理服务系统而言，尽量对用户的真实姓名等敏感字段进行脱敏显示。通用做法是在后端VO层把需要展示的字段统一处理后再返回前端，不在Controller把Entity直接返回。

7.4 从开发过程到论文撰写的衔接

写论文时，建议把技术架构、系统设计、系统实现、系统测试这四个部分作为骨干。数据库设计优化这一节，可以直接把核心表的字段设计、E-R图以及关键索引设计放上去；系统实现可以重点描述测评计分算法、排班并发控制、ECharts大屏统计这几个亮点。

测试环节不要只写“功能测试通过”这样干巴巴的几个字，要按“功能模块-测试用例-预期结果-实际结果-结论”的表格方式展开，把边界情况（如未登录访问测评接口、同一学生重复预约同一个咨询师、管理员停用账号后该账号无法登录）真实跑出来的数据和截图放上去，论文质量会显得完整很多。

根据我个人的项目经验，这类系统最终答辩能否拿到高分，核心并不在用了多少新奇框架，而在于你是不是把校内这个真实场景的需求摸透了、把业务流程理顺了，并能在现场讲清楚每个表为什么这么设计、每个关键接口的并发和状态是如何控制的、测评分数背后是否有一定依据支撑。真把心理测评的量表逻辑和咨询预约状态机都完整跑通，这个项目就算被你吃透实质性内容了。

最后分享一个自己的小习惯：把“数据字典”提前立成一个Excel表，里面包含每个常量的含义、取值来源、后端枚举名、前端展示文案，比如预约状态0待确认/1已确认/2已完成/3已取消、排班状态0可约/1已约/2停用。这个表在整个开发期间几乎不用离开手边，它会同时成为你前端下拉框选项、后端常量类定义和论文数据字典章节三个地方的唯一数据源。别小看这一步，真到开发后期能帮你省掉大量来回翻代码的碎片时间。