企业官网建设流程全解析

计算机毕业设计做到心理测评这个方向的，每年找我咨询的都挺多。说实话，市面上那种纯“增删改查”的商城、图书管理系统早就烂大街了，答辩时老师一听题目就觉得没技术含量。但心理测试评估小程序——基于SpringBoot的心理健康测评与干预服务平台，这个题目很不一样。它把测评算法、数据分析、风险预警、内容推荐、咨询预约全部串在一条业务链上，后端能展示SpringBoot的核心能力，前端小程序又能体现C端产品的交互细节，Java方向的同学拿来做毕设，只要做得完整，基本就是“保良争优”的底子。

这篇内容我会从选题拆解、技术选型、核心功能实现、前后端联调、答辩准备这五个维度完整展开，全程用我实际做过的项目经验来讲。无论你现在是刚开题、已经写完代码准备排错，还是临到答辩想补亮点，这篇都能直接给你参考。

1. 项目到底做什么：功能边界与核心设计思路

1.1 为什么选“心理测评与干预”这个场景

心理测评小程序的核心价值，是给用户提供一个便捷、低门槛的心理健康状况评估入口。用户不用去医院排队，在小程序里就能完成标准化量表的测评，系统后端自动计算分数、生成报告、给出干预建议，还能在线预约咨询师。这是一个典型的“健康服务类”C端产品，业务闭环清晰，逻辑链条完整。

从毕设的角度看，这个场景最大的好处是“技术点能真正落地”，而不是为用而用。测评计分涉及算法逻辑，报告生成涉及数据处理和格式化输出，预警名单涉及规则引擎，干预内容推荐涉及标签匹配，咨询预约涉及状态机流转。每一个模块都有明确的业务含义，老师追问“你为什么要这样设计”时，你不会没东西讲。

1.2 功能模块如何划分：用户端、咨询师端、管理端

我把这个项目按角色拆成三个端：

• 用户端（小程序）：账号注册登录、量表列表、在线答题、测评历史、测评报告、趋势图、咨询师列表、预约咨询、干预内容查看。
• 咨询师端（小程序或管理后台）：个人简介维护、预约日历、预约确认与取消、咨询记录填写、待处理预警用户查看。
• 管理端（Web管理后台或小程序内管理页）：量表管理、题目管理、用户管理、咨询师审核、预约管理、干预内容管理、预警名单管理、公告管理。

这个划分方式很关键。很多毕设项目只做“用户+管理员”两个角色，但心理测评平台如果少了咨询师这个角色，整个“咨询辅助”的闭环就断了。你想想，测评完了用户想找咨询师聊聊，却没有预约入口，那这个平台的“干预服务”就成了空话。加上咨询师端，系统角色立刻丰富起来，数据库表也会更完整，答辩时功能列表能多写一整页。

1.3 边界控制与服务定位

这里我要特别提醒一句：心理测评系统不等同于专业的医疗诊断系统。你做的是“心理健康状况的辅助筛查与日常监测”，不是“精神疾病诊断工具”。因此用户在完成测评后，报告里一定要有一句明确的提示：本结果仅供参考，不构成医疗诊断建议，如有需要请前往专业医疗机构。业务代码里也要体现这个边界，比如风险等级为“重度”的用户，系统提示“建议尽快寻求专业帮助”。这既是产品伦理问题，也是答辩时导师一定会问到的“你如何保证系统安全合规”的答案之一。

2. 技术选型与架构设计：为什么是SpringBoot + 小程序

2.1 后端技术栈的取舍与理由

后端技术栈我推荐的是：SpringBoot 2.7.x + MyBatis-Plus + MySQL 8.0 + Redis + JWT + Maven。这套组合在Java毕设里属于“标准高配”，稳定、资料多、遇到问题搜得到答案。

SpringBoot的唯一优势不多说，但要注意版本坑：很多教程给的是3.x版本，如果你的电脑是JDK8，直接跑3.x会报错。所以我建议用2.7.x配JDK8，这是最省事的组合。MyBatis-Plus最大的价值是让你少写大量单表CRUD的XML，分页、条件构造器都能直接用，开发速度至少提升30%。Redis在这里不是摆设，干什么用？做测评报告的临时缓存、验证码存储、JWT黑名单。如果用量表多、并发大的场景说Redis做缓存，但毕设能讲清楚“为什么不能用MySQL硬扛”就够了。

JWT做登录态管理，没有副作用，天然适合小程序这种跨端场景。Session方式在移动端API调用时维护成本高，JWT就一个token字符串，后端只做签名校验，无状态，扩展方便。还有一点：答辩时老师知道你用了Session反而不加分，用了JWT反而可以展开聊一聊。

2.2 小程序端：原生还是uni-app

小程序端主要有两个选择：微信原生小程序和uni-app。

如果你的毕设时间紧、只想快速出效果，我建议原生微信小程序。它不需要额外学习跨端框架，页面结构简单，组件调用直接，开发者工具里还能直接模拟不同机型。需要拆分的模块无非是：登录页、首页、量表列表页、答题页、报告页、我的页面、预约页。

如果你后续想把它同时跑在支付宝小程序或App上，可以用uni-app。但要注意uni-app的坑也不少：用Vue3语法写，部分微信小程序原生组件需要额外的条件编译。毕设阶段我不推荐为了“炫技”而引入不必要的复杂度，能用原生解决就原生解决。

唯一必须注意的，是小程序不能直接请求http接口。本地调试时：在微信开发者工具右上角“详情”里勾选“不校验合法域名”，否则什么都调不通。这个坑几乎每个人都踩过，我后面会细讲。

2.3 数据表规划与关键设计

数据库设计直接决定项目后期能不能扩展。根据功能，我建表的思路如下：

核心表：

• 用户表（user）：id、openid、nickname、gender、birthday、phone、register_time
• 咨询师表（consultant）：id、user_id、name、avatar、title、specialty、introduction、audit_status
• 量表表（scale）：id、name、description、type、total_questions、is_active、sort
• 量表题目表（scale_question）：id、scale_id、question_text、options_json、factor、score_type、is_reverse
• 测评记录表（assessment_record）：id、user_id、scale_id、answers_json、total_score、factor_scores_json、risk_level、create_time
• 预约表（appointment）：id、user_id、consultant_id、appointment_time、status、location、remark
• 干预内容表（intervention_content）：id、title、content、type、tags、suitable_factor、is_active
• 咨询记录表（consultation_record）：id、appointment_id、consultant_id、user_id、content、record_time

两张关键表我要特别说一下。

量表题目表里的 options_json 和 answers_json，我都建议用JSON字段来存。为什么？因为一份量表里的题目选项格式可能是1-5分制、1-4分制，甚至ABC文字选项，如果用固定字段设计成score选项和letter选项，用起来非常僵化。JSON字段虽然不适合做复杂SQL查询，但对测评场景来说，答题时解析题面、提交时存储答案，性能完全够用。

测评记录表里的 factor_scores_json 是用来存各个因子维度得分的。用户做一次测评，可能涉及9个因子维度，如果你建一张因子得分表，每次查询要联表、聚合、拼接，代码繁琐，报表也不好生成。用一个JSON字段存好各因子得分，生成报告时直接解析，效率非常高。

3. 核心功能落地：测评、预警、推荐、预约怎么实现

3.1 测评流程与计分逻辑

测评模块是整个系统的灵魂，也是毕设代码里最有技术含量的部分。流程是这样的：用户进入量表列表页，选择一个量表，点击开始测评；系统按顺序加载题目；用户完成所有题目后点击提交；后端接收答案，计算得分，生成报告，并返回结果。

计分逻辑看起来简单，但坑很多。我以一个90道题目的通用量表为例说明。量表里有几个维度，每个维度包含若干题目。每个题目的得分是选项对应的分值（比如：没有=1分，轻度=2分，中度=3分，偏重=4分，严重=5分）。但要注意反向计分题，比如某些题目是正向描述，需要反过来给分。判断是否反向的字段就在 scale_question 表的 is_reverse 字段里，代码中遇到 is_reverse=1 时，用“最大值+最小值-原始得分”来换算。

总分、总均分、阳性项目数的计算方式是：总分=所有题目得分之和；总均分=总分/题目数量；阳性项目数=得分≥2分的题目数量。各因子得分则是该维度下所有题目的平均分。举例：如果“焦虑因子”下有10道题，总分35分，那焦虑因子得分为3.5。生成报告时，系统根据各因子得分画出柱状图或雷达图，直观展示用户在不同维度的状态。

3.2 量表维度解析与报告生成

报告是整个测评体验的核心输出，不能只给一个数字，必须让用户看到自己的状态分布。我做的报告包含这几块：总体结果概览（总分、总均分、风险等级）、因子得分明细、既往测评趋势图、干预建议。

因子维度怎么设计？以经典量表习惯来举例，大致可以分成焦虑、抑郁、敌对、恐怖、偏执、人际关系敏感等若干维度。每个维度对应一个 score_limit：轻度范围、中度范围、重度范围。后端计算完因子得分后，根据区间映射生成对应文字描述。比如“人际敏感维度3.2分，明显高于常态范围，提示近期可能存在人际交往方面的困扰”，然后给出对应的干预建议，比如“建议进行以下放松训练：XX音频”。

报告生成后要存到Redis里做热缓存，同时异步写入MySQL。为什么用Redis？因为用户提交答卷后，3秒内必须看到报告页面。如果每次都要实时聚合题目、计算、组装模板，接口响应会比较慢。我的做法是：用户提交后先把原始答案和计算结果写入Redis，响应前端报告；同时丢一个异步任务到线程池里，把完整记录落库。这样体验流畅，数据库压力也小。

3.3 风险分级与预警策略

风险分级是评测量表里最重要的安全机制。我用的规则很简单：综合总均分和各因子得分，取最高风险等级作为最终结果。比如总均分在2到3之间为轻度，3到4之间为中度，4分以上为重度；但某个因子单项超过3.5分时，触发中高风险预警。判断结果落在风险等级后，系统自动处理后端逻辑。

预警处理分两类：一类是“双高预警”，即测评分数达到中高风险，系统会把这个用户加入到预警名单表，并推送消息给咨询师端的管理人员；另一类是“趋势预警”，比较用户最近两次测评的数据，如果总分上升超过15%，系统提示“状态正在变差，建议回访”。这个趋势判断逻辑不算复杂，但能体现你对业务的理解，答辩时很加分。

有一点要注意：风险用户查看权限。普通用户登录后只能看自己的报告，但咨询师能看到一个由系统筛选出来的“重点关注名单”，这个名单不能由用户自己关闭，只能由咨询师或管理员处理。这样设计是为了避免高危用户本来需要帮助却主动隐藏自己的状态。

3.4 干预内容推荐逻辑

干预内容推荐是整个平台“服务闭环”的最后一环。测评完不能让人干看着分数就走了，平台应该根据测评结果给出对应的干预内容——科普文章、放松音频、活动建议等。

推荐逻辑我没用复杂算法，而是用标签匹配加规则排序。干预内容表里有一个 suitable_factor 字段，记录这条内容适合哪个因子维度，另一套匹配规则看“风险等级”。假设用户焦虑因子得分偏高，系统会筛选出标签为“焦虑”的干预内容，再按内容类型排序返回。这个逻辑简单、可解释、好维护，答辩时你能讲清楚“为什么不用协同过滤算法”——因为样本量不够、冷启动严重，规则推荐反而是更务实的方案。

如果想让项目看起来更有深度，可以再加一层“因子差匹配”：取用户得分最高的两个因子，与干预内容标签求交集，匹配度高的排前面；如果某个用户所有因子都正常，则推荐心理科普类内容，而不是强行推荐治疗类内容。这种细节上的“业务敏感度”比写复杂的推荐算法更能打动老师。

4. 前后端联调与部署上手实操

4.1 本地联调最顺手的配置

开发阶段最烦的就是小程序和本地SpringBoot服务联调。核心问题就一个：小程序端默认情况下不允许访问任意http接口。解决方案我已经提过，在开发者工具的“详情”设置里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”，同时后端要配置跨域支持。

跨域配置我推荐用实现WebMvcConfigurer的方式写，不建议只靠@CrossOrigin注解，因为小程序端和后端对接时，如果接口路径前缀统一，用全局配置更省事：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .maxAge(3600); } }

如果你对接的是本地IP而非localhost，也要注意：手机真机预览时，不能用localhost访问后端，必须使用电脑的局域网IP地址，而且小程序后台域名白名单在开发模式下可以暂时不配。另外，SpringBoot启动端口建议固定为8080，避免每次启动随机端口造成小程序端配置混乱。

4.2 小程序端登录与接口封装

小程序登录和后端JWT签发是联调工作中最核心的环节。用户在小程序端点击登录，用wx.login方法拿到临时code，把code传给后端；后端调用微信接口换取openid，再根据openid查找或创建用户，最后生成JWT返回给小程序。小程序把JWT存到本地缓存，之后每个请求带上Authorization请求头。

这里有个很多新手容易踩的坑：微信小程序的wx.login获取的code只能一次性使用，而且有效期只有几分钟。调试的时候如果频繁测试登录逻辑，很容易把code用完，导致等下再试就失效了，然后怀疑代码有问题。正确做法是：后端在接收到code后立刻换取openid并返回token，小程序端不需要保存code，用完就丢。

接口封装我建议统一走request.js工具类，把url、method、data、header统一管理。每个页面的请求都走这个封装，方便做统一loading、错误提示、状态码拦截。如果token过期，后端返回401，前端统一跳转登录页重新授权并静默登录，用户体感几乎无感。

4.3 打包部署流程

毕设项目一般要到答辩前一天才部署到服务器，这一步必须提前演练，不要临时抱佛脚。

后端打包用Maven执行package命令，生成jar包。JDK8对jar运行参数的兼容性很好，直接nohup java -jar xxx.jar &跑起来。服务器上有MySQL和Redis的话，注意改配置文件。不要在本地把数据库连接串写死，建议放到application-prod.yml里，用环境变量覆盖。数据库初始化脚本要单独导出，到时重启服务器后一键导入。

小程序端上线需要先完成微信认证（个人主体也能申请，但部分接口受限），然后在微信公众平台配置“业务域名”和“服务器域名”。注意：request合法域名必须是HTTPS域名，http无法上线发布。如果只是校内演示，用内网加开发版小程序就够了，但如果你要让老师或同学扫码体验完整功能，一定需要一个公网HTTPS服务器。买一台每年几十元的轻量云服务器加上免费SSL证书即可，这些内容不展开说，但部署细节一定要提前两周测通。

5. 答辩准备与常见问题排查实录

5.1 导师必问的技术问题与回答思路

答辩时导师最爱问的不是“你的代码量多少”，而是“为什么这么做、有没有想过别的方案”。结合我自己的经验，至少有六个问题值得提前准备。

第一个问题：为什么用JWT不用Session？这是必问。答：JWT无状态，适合前后端分离场景；小程序端每次请求把token放请求头，无需额外维护session存储；但也要说出JWT的缺点，比如token无法主动失效，所以要配合Redis黑名单使用。能说出缺点，说明你真的懂。

第二个问题：Redis在你的项目里解决什么？答：测评报告缓存、验证码存储、JWT黑名单、排行榜数据等。要注意别只说“缓存”，要把场景说清楚。

第三个问题：数据一致性怎么保证？尤其是测评报告需要先写Redis再异步落库这个场景。答：引入异步任务，配合补偿机制；如果写入MySQL失败，用定时任务扫描Redis中未落库的记录进行补偿。能谈到这个深度，导师基本不会再追问。

第四个问题：你的量表题库设计为什么用JSON字段？答：因为量表题型格式多样，统一表结构会浪费大量列；题目与选项一一对应的维度变化频繁，用JSON更灵活。但也要说明JSON字段的代价：无法高效查询，所以没有在关键业务场景滥用。

第五个问题：如果并发量高，测评接口怎么优化？答：从三个层面：MySQL索引优化、Redis缓存热数据、Nginx反向代理+水平扩容。毕设阶段能讲到这三个层面已经足够。

第六个问题：这个系统做过安全防护吗？答：用户密码通过BCrypt加盐存储、JWT有效期限制、敏感接口幂等性校验、管理端权限校验、测评报告展示时做数据越权校验。这些点都能在代码里找到对应实现，讲出来非常有说服力。

5.2 演示环节的“剧本式”准备

答辩演示最怕的是“现场翻车”，所以你要准备一套“剧本式”的演示流程：注册登录一个测试账号，提前准备一份完整的测评数据、一个预警用户、一个咨询师账号。演示时依次按这个顺序走：进入小程序首页，展示量表列表；选择一份量表，按正常速度完成测评；展示测评报告页面和雷达图；切换历史记录页展示数据趋势图；退出用户，切换咨询师账号，登录后重点展示预警用户列表；新增一条咨询记录；再切换到管理后台，展示用户管理和公共内容管理。

每一步都要有个“串场词”。比如展示雷达图时说“这里能直观看到用户各因子维度的分布，比一个总分更清晰”；展示预警名单时说“系统根据测评分数自动识别出风险用户，咨询师端可以直接看到”；展示后台时说“量表题目和干预内容是动态配置的，即使后期业务新增量表，也不用改代码”。一边演示一边讲设计思路，比单纯跑一遍页面有效得多。

另外，演示前脑子里过一遍这些关键路径有没有bug：登录是否耗时、测评提交是否卡顿、报告是否出现数据错乱、切换账号是否影响缓存。提前把测试数据固定好，准备一份测试账号专册，别到时候临时注册新账号，一来一回浪费时间。

5.3 常见Bug清单与排查经验

我把实际项目里踩过的典型坑整理了一下，这些大概率你也会遇到：

第一，本地调试时小程序请求接口报错“不在以下 request 合法域名列表中”。解决办法前面说了，勾选开发者工具的“不校验合法域名”。如果已经勾选还不行，检查后端跨域配置是否真的生效，可以在后端加一个拦截器打印请求头，看看Authorization和Content-Type是否都带上了。

第二，部署到服务器后，小程序端请求正常，但后端访问数据库超时。这个问题大多出在数据库版本和编码上。MySQL8默认字符集是utf8mb4，但旧表可能还是utf8，导致中文乱码。在JDBC连接串中显式指定characterEncoding=utf8mb4和serverTimezone=Asia/Shanghai。

第三，时区问题：评测记录的 create_time 在MySQL里查出来比当前时间早了8小时。解决办法是在JDBC连接串里加 serverTimezone=Asia/Shanghai，同时确认服务器系统时区也设置为UTC+8。这个问题看似小，不过演示时被老师和同学看到时间不对，印象会大打折扣。

第四，JWT过期后用户操作报401，但前端没有跳转登录页。排查思路：检查封装的request.js里是否对401状态码做了统一处理，是否从本地缓存中清除token并跳转登录页。如果小程序开发工具的缓存没有清理，旧token一直存在，反复复现这个问题。解决办法是开发调试时每次改完登录逻辑，都要清缓存重试。

第五，事务失效问题。比如创建测评记录时，如果同一个类里的方法互相调用，事务注解可能不生效。这是因为Spring事务基于AOP代理，内部调用不经过代理对象。解决办法是拆分Service类或在启动类上加上@EnableTransactionManagement，并且把事务方法放在public接口上。这类问题在答辩时拿出例子来讲，导师会认为你踩过坑、有真经验。

第六，异步落库时MySQL死锁或主键冲突。比如同一个用户同时提交两次测评请求，因为主键生成策略冲突报错。解决方案是接口层做幂等校验，同一个用户对同一份量表，在测评周期内只允许生成一条记录；同时在前端用互斥锁，提交过程中按钮置灰，禁止重复点击。这个方案组合拳下来，基本不会出问题。

第七，小程序端真机调试时，console里看不到报错信息。这个问题很常见，因为真机日志比较隐蔽。建议先把接口调试全部在开发者工具里完成，真机预览时重点看网络请求能否通，如果接口数据库连接有问题，可以看服务端日志，而不是在手机上找半天问题。

最后说几句

毕设这一路从选题到答辩，打磨最多的其实不是技术，而是对整个系统业务链条的理解。心理测评这个题目之所以适合拿来做Java毕设，是因为它包含了一个完整C端产品从测评到干预再到预约的全链路逻辑，数据库表、接口设计、业务状态流转都有实打实的复杂度，你能讲的“故事”非常多。做一个好的毕设，代码写完只是第一步，能把自己每一步的选择用业务逻辑讲圆，才是答辩拿高分的关键。我自己的体会是，认认真真把风险预警、推荐和预约这些模块串起来做一遍，比刷十套面试题都有用。

如果你准备做这个项目，建议拿到需求后先花一个晚上把功能模块和数据库表理顺，不要上来就写代码。数据库结构定了，后面整个项目的开发节奏会顺畅非常多。祝你的毕设顺利完成，有什么卡住的地方，欢迎随时来交流。