重离子猫猫1. 项目概述与背景分析
1.1 为什么是社区心理健康服务系统
这两年社区治理越来越精细化，心理健康从“个人私事”变成了基层公共服务的一部分。我在筹备毕业设计时观察到，传统社区心理服务主要依赖线下预约、电话沟通这种方式，预约效率低、居民不好意思开口、咨询记录分散在纸质档案里，社区工作人员想做个心理普查或随访汇总，数据根本拉不出来。这类问题不解决，服务就很难真正落地。
SpringBoot社区心理健康服务系统想要解决的就是这么一个问题：让居民能在线预约咨询、做心理自评、看科普文章，咨询师能管理排班和跟进个案，社区管理员能掌握整体服务数据。从技术角度来看，这是一个典型的前后端分离业务系统，核心是角色权限、流程管理和数据可视化，没有太刁钻的算法，但工程化要求不低。作为毕业设计，它的功能边界清楚、技术栈主流、业务有现实关切，答辩时能讲的东西很多。
如果你正打算做类似的系统，或者手里已经有一份需求文档但不知道从哪里下手，这篇文章全流程讲的是我做这套系统时的真实过程——从需求拆解、数据库设计、SpringBoot核心实现，到JWT权限、咨询预约、数据看板这些模块怎么落地，再到部署中的坑。没有废话，都是可以直接拿去用的经验。
1.2 SpringBoot技术选型的价值点
先说结论：这个项目用SpringBoot 2.7.x做后端，是稳妥且足够亮眼的选择。SpringBoot在社区服务类管理系统里几乎处于统治地位，原因很实在。
第一，自动装配机制极大减少了配置成本。我不用像传统SSM那样手动拼一堆XML，一个spring-boot-starter-web就搞定了内嵌Tomcat和MVC。这对毕业设计来说，意味着可以把时间花在业务逻辑上而不是环境搭建上。
第二，SpringBoot生态对“管理系统”这类CRUD密集型项目支持非常完整。Spring Data JPA或MyBatis-Plus任选，Spring Security做安全控制，Redis做缓存，Actuator做监控，都有对应的Starter可以直接整合。
第三，后端技术栈不至于“太老”或“太偏”。SpringBoot现在已经是企业级Java开发的默认选项之一，面试时能聊的点也很多——比如自动装配原理、条件注解@ConditionalOnXxx、starter机制、循环依赖解决方式等。这些在毕业设计答辩时都是加分项。
顺便提一个容易被忽略的点：版本选择。我用的SpringBoot 2.7.18，而不是3.x。原因很简单，3.x基于Jakarta EE 9+，javax包要换jakarta，JDK最低要求17。很多学生电脑上还是JDK 1.8，如果硬上3.x，环境就劝退一批；另外学校机房如果跑老版本数据库驱动、旧版本MyBatis，兼容性也容易出问题。SpringBoot 2.7是2.x的最终版本，bug修复完整，资料又多，最适合拿来做毕业设计正文中强调的“稳定落地”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体设计思路与核心业务拆解
2.1 用户角色与核心业务流程
这套系统在需求阶段就确定了三类角色，这种设计也是答辩时的核心亮点之一——不是单角色CRUD，而是真实的业务协同。
| 角色 | 核心诉求 | 主要操作 |
|---|---|---|
| 居民用户 | 隐私、便捷、低门槛求助 | 心理自评、在线预约、查看报告、阅读文章 |
| 心理咨询师 | 管理排班和来访者、跟进咨询记录 | 排班管理、预约审核、咨询记录、评估量表管理 |
| 社区管理员 | 服务数据总览、资源分配 | 用户管理、咨询师审核、数据统计、公告配置 |
业务流程我用一句话就能说清楚：居民提交“心理自评问卷”，系统自动算分；分数异常则推荐预约咨询；居民在咨询师的可预约时段内提交预约申请；咨询师在后台确认；咨询完成后填写咨询记录，居民可以在“我的档案”里查看历史记录和趋势。这个闭环逻辑完整，而且每一环都能对应数据库表和接口，不会被质疑“功能是拼凑的”。
2.2 为什么不是简单的“文章展示+留言板”
很多社区类系统做出来就变成内容管理系统（CMS），本质上是新闻发布加留言反馈，这偏离了“心理健康服务”的核心。我的取舍原则是：必须能在系统内完成一次“心理求助到咨询跟进”的服务闭环。所以需求层面就把以下四个模块定为“必须实现”：
- 心理自测量表：前端渲染题目，提交后后端按规则计算得分，而不是前端算完给个结果就完事
- 预约-审核-完成流程：时间段排期用数据库表实现，状态机流转清晰
- 咨询记录与随访：咨询师视角的数据记录，而不是居民在留言板里倒苦水
- 数据看板：管理员能看到按社区、按月份的咨询量、异常预警数量，用于资源调配
技术难度都不大，但每个都有业务深度，能让答辩评委觉得“这个学生是真的理解需求，而不只是实现增删改查”。
2.3 技术架构与系统边界
我采用的是标准的B/S前后端分离架构。
后端：SpringBoot作为核心框架；MyBatis-Plus操作数据库；Spring Security + JWT做认证授权；Redis缓存验证码和热点数据；数据库用MySQL 8.0。文件存储用本地磁盘目录，避免引入FastDFS或OSS，降低部署复杂度。定时任务用Spring原生@Scheduled，处理咨询结束自动归档之类的事情，没必要为了展示技术硬上Quartz（除非你想在简历里提一嘴分布式任务调度）。
前端：Vue 2 + Element UI，这是一套成熟的组合，社区资料极多，组件现成，我主要精力花在页面逻辑而不是造轮子。图表使用ECharts，做管理员趋势图。
这套架构决定了项目的可靠底线是“能跑通、演示顺畅、部署不复杂”。毕业设计现场演示如果数据库老连接不上、跨域配置出了问题、接口报500，哪怕功能再全也容易减分。
3. 数据库设计与核心表结构详解
3.1 设计原则：表与业务流程一一对应
数据库设计是这个项目真正拉开差距的地方。我一开始画了十几张表，后来发现有些表字段冗余严重，比如“咨询记录”和“咨询师跟进记录”其实是两回事，别合并；而“文章表”和“分类表”关系简单，也别过度设计。
最终核心建了这些表：
user：用户表，字段含用户名、密码、角色、所属社区ID、手机号、状态；角色字段直接用role区分，USER/COUNSELOR/ADMIN，不单独做RBAC权限角色表，因为系统不需要细粒度权限，做多了反而显得假。assessment_scale和assessment_question：量表和题目表，量表有类型字段，如SCL-90简化版、焦虑自评量表SAS等。assessment_record：居民自评结果记录，最重要的字段是total_score、level（正常/轻度/中度/重度）、advice。counselor_schedule：咨询师排班表，记录某天某时段的剩余号源。appointment：预约表，状态字段：PENDING待审核、CONFIRMED已确认、COMPLETED已完成、CANCELLED已取消。consultation_record：咨询记录表，咨询师填写，居民不可见（隐私设计的关键点）。article和article_category：科普文章。
3.2 关键设计细节
时间段的处理上，我把开始时间和结束时间拆成两个字段，start_time和end_time，而不是存一个“第几节”。原因很简单：心理咨询的时长为50分钟到1小时不等，如果固定成“第1节”“第2节”会让系统很死板，咨询师排班就是设置“本周三14:00到15:00”，居民看到的就是一个真实可预约的时间点，这样最直观。
外键策略上，我没有物理外键，只在代码层通过@TableId和@TableField维护逻辑关系。