眠子子子做毕业设计这些年，我见过太多人栽在同一个地方：选题看着热闹，做起来才发现要么技术栈太旧没法写进简历，要么功能太少撑不起一篇论文。如果你正在犹豫要不要做“心理测试评估小程序”这类题目，我可以直接告诉你结论——这是一个性价比很高的毕设方向，但前提是你得搞明白它背后的设计逻辑，而不是拿到一个开源项目就急着跑起来。
这篇文章我会把“基于Spring Boot + 微信小程序的心理健康自助平台”这个项目从选题价值、技术选型、模块拆分、联调排错到论文撰写，整个链路拆开讲一遍。不只讲“怎么做”，更会讲清楚“为什么这么做”，以及我实际开发中踩过的坑。项目的核心关键词是Spring Boot、小程序、计算机毕业设计，这三个词组合起来，恰好覆盖了后端开发、移动端适配、数据库设计、部署上线这几个高校考核的高频点。
1. 为什么心理测评小程序值得做成毕设：选题价值与技术覆盖面
1.1 这个选题解决了什么真实问题
心理测评类产品在市面上并不少见，但高校场景下的需求一直被忽视。很多高校的心理健康中心还在用纸质问卷或者Excel表格收集学生测评数据，辅导员想查看某个班级的整体心理状态，得手动汇总，效率低不说，数据还容易出错。而一个“智慧心理健康自助平台”的核心价值，就是把这套流程搬到线上：学生打开微信就能做测评，系统自动判分、生成报告，辅导员和心理咨询师能看到分级预警列表，学校层面能拿到匿名的统计数据。
这个场景对于毕设来说非常讨巧，因为它业务清晰、角色分明。普通用户（学生）、管理员（心理中心老师）两个主要角色，加上测评、报告、留言、预警这些具体功能，足够构成一个完整的业务闭环。更关键的是，这个场景有明确的“非功能需求”——隐私保护、分级预警、数据统计，这些都能成为论文里的亮点章节。
1.2 从技术考核点反推项目设计
毕设答辩时老师最常问的问题不是“你用了什么框架”，而是“你的系统解决了什么问题，用了什么方案解决的”。Spring Boot + 小程序的组合天然能接住这类追问，因为技术覆盖面足够宽：
- 后端用的是Spring Boot，牵扯到RESTful API设计、Spring Security或Sa-Token做鉴权、MyBatis-Plus操作数据库、全局异常处理、参数校验这些高频考点；
- 前端是微信小程序原生开发，涉及登录态管理、页面路由、组件化开发、Canvas绘制图表这类客户端问题；
- 部署环节可以用云服务器或者Docker，牵扯到环境配置、域名备案、HTTPS证书，这部分是简历上的加分项。
这套组合能讲的东西很多，答辩时老师问任何一个技术点，你都有实际代码可以对应，不至于“一问三不知”。
1.3 项目交付物的核心构成
毕业设计交付的东西不只是代码，而是一整套“能证明你独立完成了一个项目”的材料。这套项目按“程序 + 文档 + 讲解 + 定制”四个维度来看：
- 程序指可运行的前后端源码，后端打包成jar包，小程序端能导入微信开发者工具直接跑通；
- 文档指开题报告、中期检查、论文正文、答辩PPT，核心是论文中的需求分析、数据库设计、系统测试三章；
- 讲解指能对着PPT把项目讲明白的能力，这个在后面专门有一节讲；
- 定制指针对自己学校的业务细节做调整，比如测评量表换成学校心理中心实际使用的版本，或者在系统里增加“院系”“年级”这类学校特有属性。
我见过很多同学拿到一个完整项目后直接改个名字就交上去，结果答辩时被老师问一句“这个表为什么这么设计”就卡住了。所以我会在下面把每一个模块的设计思路都写清楚，帮助你真正吃透这个项目。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型背后的五个判断：版本、框架、数据库与鉴权方案
2.1 Spring Boot版本选择的严肃性
把版本放在第一位，是因为这里面的坑最多。很多人习惯性地去官网下载最新版Spring Boot，结果在配置的时候发现一堆兼容性问题，甚至项目都启动不起来。
以Spring Boot 3.x和2.x的选择为例。Spring Boot 3.x最低要求JDK 17，如果你的电脑装的是JDK 8，那直接选Spring Boot 2.7.x更稳妥。不要小看这个问题，开发环境、服务器环境、答辩演示环境如果JDK版本不一致，很容易出现“在我电脑上能跑，在你电脑上报错”的情况——这在毕业设计答辩时是灾难级的失误。
从生态适配角度看，当前阶段选择Spring Boot 2.7.18是一个理性的决定。这个版本属于2.x系列的最终维护版本，稳定性好，无论是MyBatis-Plus、Sa-Token还是微信支付SDK，都有明确的兼容版本。而Spring Boot 3.x虽然性能有提升，但一些老教程里的代码不能直接复制，比如javax.servlet要改成jakarta.servlet，这个改动对于不熟悉Maven依赖管理的同学来说，排查起来非常痛苦。
2.2 小程序端的技术选型：原生还是Uni-app
微信小程序端的开发方式有三种主流选择：原生小程序、uni-app、Taro。对于毕业设计场景，我的建议很明确：如果之前没有Vue或React基础，直接用原生小程序；如果会Vue，可以选uni-app。
原生小程序的好处是文档全、报错信息明确、微信开发者工具直接支持，不需要额外构建步骤。缺点是代码结构比较啰嗦，每个页面需要四个文件（js、json、wxml、wxss）。uni-app的好处是一套代码可以编译到微信小程序和H5，但多了一层构建环节，遇到问题排查链路更长。
我做这个项目时推荐原生小程序，原因之一是答辩时老师会问“页面之间的数据怎么传递”“组件的生命周期是什么”，这些用原生代码讲起来最直观。另一个原因是这个小程序的功能并不复杂——首页、测评列表、测评详情、测评答题页、个人中心、管理后台，大概十几个页面，原生代码量完全可控。
2.3 数据库设计：表结构如何支撑业务逻辑
这个项目的数据库设计是整个后端开发的基石。结合典型业务，我建议至少设计以下数据表，具体的字段设计需要根据实际需求细化：
user表：用户ID、微信openid、昵称、头像、手机号、角色（普通用户/管理员）、创建时间；scale表：量表ID、量表名称、量表描述、题数量、适用人群、创建时间；question表：题目ID、所属量表ID、题目内容、选项类型、排序号；option表：选项ID、所属题目ID、选项内容、选项分值；record表：测评记录ID、用户ID、量表ID、总分、结果等级、测评耗时、创建时间；answer表：答题明细ID、测评记录ID、题目ID、选中选项ID、得分；message表：留言ID、用户ID、内容、是否回复、回复内容、创建时间；admin表：管理员ID、账号、密码、姓名、角色。
这个设计的思路是把一次测评行为拆成两个层级：record记录“谁在什么时候做了哪个量表”，answer记录“每一道题选了哪个选项”。这样设计的直接好处是，统计“这个学生最近三次测评的分数变化趋势”时，一条SQL就能查出来，不需要解析JSON文本，性能和数据可维护性都有保证。
2.4 鉴权方案选型：JWT还是Sa-Token
用户登录这块，小程序端通过微信登录拿到code，后端拿code去微信接口换openid，然后生成一个自定义登录态返回给小程序。这个登录态用什么方案管理，决定了整个后端接口的安全模型。
常见的方案有JWT和Sa-Token。JWT是无状态令牌，服务器不需要存储会话信息，但存在无法主动失效的问题，如果用户被拉黑，token在过期前依然有效。Sa-Token是轻量级的Java权限认证框架，默认基于内存或Redis存储会话，可以随时踢人下线，权限控制也更细粒度，支持注解鉴权。
对于这个心理测评平台，我建议用Sa-Token。原因不只是功能，还因为它的上手成本低——引入依赖、配置拦截器、登录时调用StpUtil.login(userId)，然后前端每次请求带上token，后端使用注解或代码拦截校验即可。答辩时如果老师问“你这个系统怎么保证只有登录用户才能查看自己的测评报告”，你可以直接讲“通过Sa-Token的注解鉴权控制接口访问，未登录直接返回401”，这个回答非常加分。
2.5 部署方案：从本地到云服务器的完整链路
毕设通常需要演示，演示环境可以是本地启动后端 + 微信开发者工具打开前端，但如果你想让老师通过手机真机访问，那就得部署到云服务器上。
最稳妥的部署方案是买一台2核4G的云服务器，安装JDK 8、MySQL 5.7（或MySQL 8.0）、Nginx，然后把Spring Boot项目打成jar包用nohup java -jar xxx.jar &跑起来。Nginx的作用有两个：一是反向代理后端接口，把/api/路径转发到localhost:8080；二是配置HTTPS证书。
小程序真机调试有个硬性要求：后端接口地址必须能用HTTPS访问，不能是HTTP。这意味着你需要一个域名并且完成备案，再把SSL证书配置到Nginx上。很多同学在这一步卡住，其实可以走个捷径——如果你只是想在开发者工具里用真机预览，可以在微信开发者工具的“详情-本地设置”里勾选“不校验合法域名”，这样即使接口是HTTP也能调试。但注意，这个选项只对开发调试有效，体验版和正式版小程序不能这么干。
3. 核心功能模块的实现逻辑：从测评引擎到报告生成
3.1 测评模块的完整链路设计
测评是这个小程序的核心功能，它的完整链路是：用户打开某个量表 → 查看量表详情页 → 点击开始测评 → 逐题作答 → 提交 → 后端计算得分 → 生成测评报告 → 前端展示结果并支持查看历史记录。
这里的核心难点在后端如何设计一个通用的“测评引擎”。也就是说，新增一套量表的时候，不应该修改代码，而是通过后台配置题目和选项就能上线。要实现这个效果，需要把“量表、题目、选项、分值”都存到数据库里，后端只提供“按量表ID查询题目列表”和“接收答案并计算分数”两个接口。
答题页前端实现时有一个体验细节：要保存用户的答题进度，防止用户答到一半退出后重新开始。最直接的做法是把当前答案存到小程序的storage里，下次打开时恢复，提交成功后清除。如果数据要跨设备同步，那就得在后端提供一个“暂存答题记录”的接口，但毕设场景下本地缓存完全够用。
3.2 SCL-90量表的判分逻辑：从原始分到等级评估
心理测评平台最常见的量表是SCL-90（症状自评量表），包含90个题目，每个题目1-5分，总分范围90-450分。判分逻辑有三个层级：总分、总均分、阳性项目数。
以SCL-90为例，核心判分逻辑是：把90道题的得分相加得到总分，总分除以90得到总均分；单项分≥2的题目视为阳性项目，统计阳性项目数；再根据总均分划等级——总均分≤1.5为正常，1.5-2.5为轻度，2.5-3.5为中度，>3.5为重度。后端计算时只要把用户答案里的选项分值汇总，再套用这个规则就能得出结果。
这里要特别提醒一个业务上的注意点：心理测评结果属于敏感个人信息，系统不能把“重度”这个结论直接做成大字弹窗刺激用户。更稳妥的做法是，用委婉的语气提示“近期压力水平较高，建议预约心理咨询”，同时展示测评的时间、分数变化曲线。这个细节在论文的“系统设计”部分写出来，老师会觉得你考虑到了实际应用场景，而不只是在写CRUD。
3.3 测评报告的存储策略与展示方式
测评报告是用户最关心的产出，它的存储有两条路线可选。
第一条路线是只存record表里的总分和等级，报告内容通过前端模板根据分数动态拼接。这种做法省空间，但如果后端判分规则改了，历史报告的展示也会跟着变，而且每次查看报告都要重新拼接。
第二条路线是生成报告时把完整的报告内容（包括每道题的得分、文字分析、图表数据）以JSON格式存到数据库的一个字段里，查看的时候直接读取。这种做法适合给用户原始数值维度较少的场景，缺点是灵活性不足，后期如果要按题目维度做可视化分析会受限。
我的建议是采用折中方案：record表保存核心结论，单独增加一个report_detail字段存储报告JSON快照。这样历史报告不会因为规则调整而变动，也能快速展示。这个设计看似不起眼，但在论文的“数据库设计”章节里可以成为一个小亮点——你写出了“为什么用JSON快照而不是动态拼接”的权衡过程。
3.4 管理后台的功能边界：别做超出毕设范围的设计
很多人在做管理后台时会失控，总想做成一个功能完整的运营系统。我见过有人给心理测评平台加了公告管理、积分商城、用户会员等级，结果光后台就写了十几个表，论文却说不清楚这些功能和“心理健康自助”有什么关系。
管理后台的功能边界应该是：能维护测评业务的最小集。我做这个项目时只保留了五个功能：用户管理（查看用户列表、禁用账号）、量表管理（新增/编辑/上下架量表）、题目管理（维护量表的题目和选项）、测评记录管理（查看所有用户测评记录、按等级筛选）、数据看板（统计今日测评量、各等级占比）。这五个功能刚好覆盖了业务管理的核心需求，也能对应到论文的“功能需求分析”章节。
如果你想让项目更有亮点，可以额外加一个“消息回复”功能——用户在小程序端提交咨询留言，管理员在后台回复，回复内容同步推送到小程序端。这个功能打通了前后端数据流，还能在答辩时讲“消息推送方案”，比单纯堆CRUD页面有价值得多。
4. 前后端联调中的关键节点与拦路问题
4.1 小程序端如何拿到用户登录态
小程序登录是前后端联调的第一个关卡。它的基本流程是：小程序端调用wx.login()获取临时code，把code发送到后端接口；后端拿code加上AppID和AppSecret，请求微信的接口获取openid和session_key；后端用openid查用户表，如果用户不存在则自动注册，然后生成自定义登录态token返回给小程序。
这里最坑的点是：code只能用一次，而且有效期只有5分钟。如果你在调试时发现后端频繁报“invalid code”，不用怀疑，一定是你在一个流程里多次使用了同一个code。正确做法是每次wx.login()拿到的code只发送一次到后端，后端处理完就作废。
另外，现在的微信小程序接口调整后，前端拿用户手机号和昵称也可能遇到限制，很多开发者调用相关接口会提示“获取登录后的微信用户失败”。这种情况下不要在后端硬等微信返回用户资料，可以引导用户在小程序内手动填写昵称、头像等信息，或者在登录时用默认头像和昵称，等用户进入个人中心后主动完善。从实现角度看，设计一个允许用户自定义头像昵称，并在每次请求时通过token关联用户身份的机制，同样能完成用户系统的闭环。这个方案还顺便解决了隐私授权的问题，属于一石二鸟。
4.2 请求拦截器与token校验：前端后端的配合逻辑
联调时会发现一个普遍问题：如果每个页面都写“判断是否登录”，代码会非常冗余。前后端都需要一个统一的拦截机制。
后端用Sa-Token的话，只需要加一个拦截器，对/api/user/**、/api/admin/**这些需要登录的路径做校验。前端则在request方法里统一处理：每次请求前从storage里拿token，放到header里；后端返回401时，前端统一跳转到登录页。这个逻辑只需要维护一份代码，所有页面都复用，避免重复劳动。
小程序原生环境里，你可以在utils/request.js里封装一个request函数，统一处理baseURL、token、超时、错误提示。这样每个页面调用时只需要写业务逻辑，不用关心底层的鉴权细节。这种做法在论文的“系统详细设计”里也能画一笔，叫做“封装统一的网络请求层”。
4.3 跨域问题：接口通了但页面报错怎么办
联调中另一个高频报错是跨域问题。现象是后端接口在浏览器或微信开发者工具里直接被拦截，控制台提示CORS错误。
原因是小程序的WebView环境（或H5调试时）有同源策略限制，而wx.request本身不限制跨域，但在开发者工具里如果开了“不校验合法域名”仍然报错，多半是后端没加跨域配置。Spring Boot里最简单的方法是通过WebMvcConfigurer配置全局CORS，添加对应的允许域名或允许所有来源。
还有一种情况是后端接口路径没对上。前端请求的是/api/scale/list，后端Controller映射的却是/scale/list，这时候会报404而不是跨域。排查时要先看网络请求的URL和状态码，再决定往哪个方向排查。我实际开发中遇到过很多次这类问题，经验是：先在浏览器里直接访问后端接口测试通不通，再去小程序端排查，不要两边同时乱猜。
4.4 真机调试与环境配置：域名、HTTPS和手机预览的坑
到了真机调试阶段，会遇到一个让很多人头疼的问题：后端运行在电脑上，手机小程序却访问不到电脑的IP。
如果你是本地联调，先确保手机和电脑在同一个局域网，后端启动时监听0.0.0.0而不是默认的localhost，然后用电脑的局域网IP+端口号作为接口地址。微信开发者工具中，把“不校验合法域名”勾上，手机预览时需要在“真机调试”里把地址设为电脑的局域网IP。
如果你已经买了云服务器，部署好之后，用手机访问时要注意：体验版小程序的后端地址必须通过HTTPS访问。没有HTTPS证书的情况下可以临时用IP地址测试，但如果小程序发布正式版，域名备案和HTTPS证书是绕不过去的。对毕业设计来说，通常演示到开发者工具和真机预览阶段就足够了，可以在论文的“系统测试”里写清楚部署环境。
4.5 高频报错的快速定位思路：接口通了数据不对时先查表
联调过程中最费时间的往往不是网络层不通，而是接口通了但返回的数据不对。这种问题大概率发生在三个地方：SQL查询条件写错、参数传递类型不匹配、前端渲染字段名对不上。
我建议的排查思路是：先用Postman或浏览器直接调用接口，查看返回JSON是否正常；如果接口返回正常但小程序页面显示异常，问题出在数据绑定；如果接口返回本身就不对，去查SQL控制台打印的日志。Spring Boot加MyBatis-Plus时，可以在配置文件里开启SQL日志打印，每个请求执行了什么样的SQL一眼就能看到，排查效率会提高非常多。
5. 文档与答辩：让项目在老师面前站得住脚
5.1 论文结构怎么组织：需求驱动设计，设计驱动实现
毕设论文最常见的毛病是“先写系统怎么做，再写为什么这么做”，顺序反了。正确的逻辑应该是：从需求出发，推导出设计决策，最后落到代码实现。
我建议按这个顺序组织论文：
- 第一章绪论：写心理测评的背景和意义，引用2-3篇近年的相关研究文献，指出传统纸质测评的痛点；
- 第二章需求分析：写角色分析（学生、心理中心老师）、功能需求（用例图+用例描述）、非功能需求（安全性、易用性、性能）；
- 第三章系统设计：写总体架构（前端小程序、后端服务、数据库三层）、功能模块设计（测评模块、报告模块、后台管理）、数据库设计（ER图+表结构说明）；
- 第四章系统实现：按功能模块写实现细节，贴关键代码、截图、核心逻辑说明；
- 第五章系统测试：写测试环境、功能测试用例表、测试结果、性能测试简述。
这个结构中，第三章和第四章是核心，也是老师重点翻阅的部分。数据库设计要给出每一张表的字段说明，并解释为什么这样设计（比如为什么把答题明细分表），系统实现里每个模块先写“设计思路”，再贴代码片段，不要整页复制代码。
5.2 答辩讲解的时间分配与演示策略
答辩通常要求8-15分钟讲完，时间非常紧张。很多人的问题是太抠细节，讲了半天登录界面怎么画，老师心里会犯嘀咕：“这项目没有更深的东西吗？”
我推荐的时间分配是：2分钟讲背景和需求（为什么做这个系统），3分钟讲系统架构（一张架构图讲清楚前端、后端、数据库的关系），4分钟演示核心流程（重点演示测评→生成报告→后台查看记录这条闭环），2分钟讲技术难点和亮点（Sa-Token鉴权、测评引擎通用性、数据统计可视化），剩下的时间留给老师提问。
演示时的顺序也有讲究。先演示测评流程，因为这是系统的心脏；再演示管理后台的数据看板，因为这里能展示统计功能；最后如果有时间再演示个人信息维护等非核心功能。关键流程一定要提前多演练几遍，尤其是登录、答题、出报告这个链路，不要在答辩现场才发现某个接口挂掉了。
5.3 老师答辩必问问题的应对思路
根据我接触过的多个答辩现场，心理测评平台会遇到的提问基本集中在几个方面：
- “SCL-90的计分规则是什么”：你要能准确说出总分计算方式、等级划分标准，这个前面已经讲过；
- “数据库为什么这么设计”：从一个具体表出发，比如为什么用两个表存测评记录和答题明细——因为一次测评对应多条答题结果，一对多关系必须拆表，否则无法按题目维度分析；
- “用户隐私怎么保护”：答“测评数据只有用户本人和管理员可见，管理端不展示真实姓名，某些场景使用脱敏策略”，再提一下HTTPS传输加密；
- “部署在什么环境”：写清楚服务器配置、JDK版本、MySQL版本、Nginx反向代理的链路；
- “这个系统还有什么可以改进的地方”：准备2-3个可扩展方向，比如“接入专业心理量表更多”、“增加AI智能问答”、“生成班级维度的匿名统计报表”。
这些问题没有标准答案，但只要你亲自把代码跑通一遍、理解每一张表的作用，基本都能接住。最怕的就是项目是网购的，自己没有完整看一遍代码，被问到一个细节就露馅了。
5.4 从毕设到简历：如何把这个项目写进项目经历
做完这个项目之后，还有一个容易被忽略的环节——把项目写进简历和面试作品集。很多同学做完毕设就扔在一边，到求职时才想起来，但细节已经忘得差不多了。
写进简历时，核心思路是强调你解决的问题和采用的关键技术，而不是写流水账。比如：“基于Spring Boot、Sa-Token、MyBatis-Plus开发心理测评小程序，设计了通用测评引擎，支持量表动态配置，答题数据通过AOP记录操作日志，部署于云服务器并通过Nginx实现反向代理与HTTPS加密。”——这句话就能同时体现框架运用、业务设计、运维部署三个层面的能力。
面试被问到项目时，如果你能把这个项目的表结构、接口设计、鉴权流程讲得清清楚楚，HR和面试官通常都会认可你的动手能力。哪怕这只是课程项目级别，也比空洞地说“我熟悉Spring Boot”有说服力得多。
回到这个项目本身，如果你打算以它为模板做毕设，我的建议是：跑通基础功能后，集中精力把测评、报告、后台管理这三条链路打磨顺畅，然后写论文、做PPT、准备演练。技术上不需要追求面面俱到，但要在关键位置上做出深度。心理测评小程序这个方向，真正能拉开差距的不是功能多寡，而是你对业务逻辑、数据安全和隐私保护这些细节处的理解——这些东西，才是老师觉得“这学生真的动手做了”的理由。