每年课设季和毕设季，后台总有一批人问同一个问题：想做一个基于 Spring Boot 的管理系统，业务别太抽象，功能别太简单，CRUD 里能带一点权限、状态流转和统计报表，最后还要有源码、数据库脚本和文档，方便直接上手改。
社区康养管理系统正好卡在这个需求点上。它不是一个纯理论的课程作业，而是把“社区养老服务”这个真实场景搬到线上：老人有健康档案，服务人员能上门或预约服务，管理员能看全局数据。业务边界清楚，表结构不算复杂，但又足够撑起一份毕业设计的设计说明书。这篇文章我会把整个系统的需求拆解、技术选型、数据库设计和核心代码实现全部过一遍，最后把源码导入和常见踩坑也一并说清楚，希望能帮你们少走弯路。
1. 为什么这个系统值得做：背景、定位与需求拆解
1.1 社区康养的业务场景到底需要什么
社区康养管理系统面向的是社区服务中心、养老服务站这类场景。传统方式下，老人的健康档案是纸质表，预约上门服务靠电话，测量数据记在Excel里。问题很明显：档案容易丢、服务过程没有记录、管理人员统计起来非常痛苦。
系统要解决的，就是三个核心问题：档案电子化、服务流程线上化、运营数据可视化。老人或家属注册登录后，可以维护个人健康档案，提交血压、血糖等测量记录，在线预约康养服务；服务人员能查看预约、跟进服务状态；管理员负责审核、发布活动公告，以及查看各类统计报表。
这个业务模型非常适合作课程设计或毕业设计，因为它的功能边界清晰，不会像“电商系统”那样牵扯支付、库存、物流一堆复杂模块，同时又比单纯的学生管理系统更有业务感。你答辩的时候能讲清楚“这个系统给谁用、解决什么问题”，比堆砌再多的功能都更有说服力。
1.2 用户角色与功能模块梳理
我在设计这个系统时，把用户分成三个角色：
| 角色 | 核心职责 | 典型功能 |
|---|---|---|
| 老人/家属（前台用户） | 维护自身信息、预约服务、记录健康数据 | 注册登录、健康档案维护、测量记录添加、服务预约、查看公告 |
| 服务人员/医护人员 | 处理预约、录入服务结果 | 查看预约列表、确认服务、填写服务反馈、维护服务项目 |
| 系统管理员 | 整体运营管理与数据查看 | 用户管理、角色权限配置、活动公告发布、服务项目管理、统计报表 |
围绕这三个角色，功能模块可以划分为：登录注册与权限管理、用户管理、健康档案管理、健康测量记录管理、服务项目管理、服务预约管理、活动公告管理、数据统计报表。
1.3 我为什么推荐你们拿它做课设或毕设
直接说理由。第一，Spring Boot 的常规考点它基本全覆盖：分层架构、MyBatis-Plus 数据操作、统一异常处理、JWT 或 Session 鉴权、文件上传、定时任务、统计查询。第二，业务上有话可讲，论文和答辩 PPT 不愁没内容。第三，扩展性很强，后续想加体检报告导入、家属多端查看、消息推送，都是在现有架构上增加模块，不会推倒重来。
如果一个项目做出来只能演示“登录 + 增删改查”，答辩老师问“你这个系统解决什么问题”就很容易卡壳。但康养管理系统天然具备社会价值背景，你能从人口老龄化、社区养老资源匹配这些角度去解释系统设计动机，整体完成度会高很多。
2. 技术选型与架构设计：不要为了炫技而复杂
2.1 选型清单与背后理由
先放一张我自己实践下来的选型清单，下面逐个说原因：
| 技术项 | 推荐选型 | 选型理由 |
|---|---|---|
| 后端框架 | Spring Boot 2.7.x | 成熟稳定，教程多，兼容 JDK8，部署资料丰富 |
| ORM 框架 | MyBatis-Plus 3.5.x | 单表 CRUD 不需要写 SQL，复杂统计可自定义 XML |
| 权限校验 | Spring Security + JWT | 满足角色权限控制，答辩时有深度可讲 |
| 数据库 | MySQL 8.0 | 主流且免费，脚本通用性好 |
| 连接池 | Druid | 自带监控页面，课设里加 Druid 监控也是加分项 |
| 前端方案 | Thymeleaf + Bootstrap + Layui 或 AdminLTE | 服务端渲染，部署简单，不需要单独起前端服务 |
| 工具库 | Hutool、Lombok | 简化编码，减少冗余代码 |
| 图表展示 | ECharts | 统计报表直接引用 CDN，效果直观 |
很多人会纠结要不要用前后端分离，比如 Vue + Spring Boot。我的建议是：如果这是课程设计，优先用 Thymeleaf 服务端渲染。理由很现实，答辩环境不一定稳定，前后端分离意味着你需要同时跑后端服务和前端 node 服务，一旦端口、跨域、代理出问题，现场演示很容易翻车。而服务端渲染的应用，打包后一个 jar 跑起来，浏览器直接访问，演示成本最低。
2.2 项目分层结构与代码组织方式
项目采用经典的四层结构：Controller 接收请求、Service 处理业务、Mapper 操作数据库、Entity 映射表结构。中间再加一层 DTO 和 VO，避免前端参数直接绑定实体类。
Controller 层的职责是参数校验和结果封装，业务逻辑不要写在 Controller 里。举个最简单的例子，处理一个新增健康档案请求，Controller 只做参数接收，然后调用healthProfileService.addProfile(dto)返回统一 Result 对象。
Service 层要有接口和实现类，方便后续写单元测试。虽然课设里很少真测，但这种习惯在真实项目里非常重要，而且答辩时老师问到“为什么 Service 要拆接口”，你能答出“解耦和便于测试”，印象分会完全不同。
统一返回结果我建议定义成：
public class Result<T> { private Integer code; private String msg; private T data; }成功时code = 200，失败时code = 500，未登录或权限不足时分别返回401和403。这样前端只需要根据 code 值决定提示还是跳转，不需要关心后端抛出的异常类型。
2.3 项目结构说明与源码组织方式
拿到源码后，建议先看整体的包结构，不要急着跑起来。一个清晰的 Spring Boot 项目包结构是这样的：
com.community.health ├── config // 配置类：WebMvc、Security、Cors、MybatisPlus分页插件 ├── controller // 接口入口层 ├── service // 业务接口 │ └── impl // 业务实现 ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体 ├── dto // 接收参数的类 ├── vo // 返回给前端的类 ├── common // 工具类、全局常量、Result封装 ├── exception // 自定义异常与全局异常处理器 └── utils // JWT、日期处理等工具类resources 目录下，templates放 Thymeleaf 页面，static放 CSS、JS、图片，mapper放自定义 SQL 的 XML 文件，sql目录放初始化数据库脚本。文档的话，一般会有一份万字设计文档，内容包括需求分析、功能设计、数据库设计、系统实现和测试。
3. 数据库设计：先把地基打牢
3.1 核心表清单与设计思路
数据库表的设计决定了系统的上限。我当时设计这个系统时，没有一股脑堆很多表，而是紧扣业务需求。核心表大概 8 张，名字你拿源码时对照一下，基本上不会差太多：
| 表名 | 中文含义 | 关键字段说明 |
|---|---|---|
| sys_user | 系统用户表 | 登录账号、密码、姓名、电话、角色ID、状态 |
| sys_role | 角色表 | 角色名称、角色标识 |
| health_profile | 健康档案表 | 身高、体重、血型、过敏史、慢性病史、家族病史 |
| health_record | 健康测量记录表 | 用户ID、类型、数值、单位、测量时间 |
| service_item | 服务项目表 | 服务名称、描述、时长、适用对象 |
| service_appointment | 服务预约表 | 用户ID、项目ID、预约时间、时段、状态、备注 |
| activity_info | 活动公告表 | 标题、内容、活动时间、地点、状态 |
| sys_announcement | 系统公告表 | 标题、内容、发布时间、发布人 |
设计思路遵循一个原则：能用一张表表达清楚的，就不要拆两张表。比如用户和角色，我用角色ID字段关联，没有做成标准的三表 RBAC，因为课设场景不需要那么重的权限模型。但如果你论文里想体现更完整的权限设计，也可以改成用户表、角色表、菜单表、用户角色关联表这种模式，工作量会增加一些，但对论文深度有帮助。
3.2 关键表结构与字段说明
以健康档案表为例，这是康养系统的核心表。我给出关键建表 SQL，你们导入源码后可以对照看：
CREATE TABLE `health_profile` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '关联的用户ID', `height` decimal(5,1) DEFAULT NULL COMMENT '身高cm', `weight` decimal(5,1) DEFAULT NULL COMMENT '体重kg', `blood_type` varchar(8) DEFAULT NULL COMMENT '血型', `allergy_history` varchar(255) DEFAULT NULL COMMENT '过敏史', `chronic_disease` varchar(255) DEFAULT NULL COMMENT '慢性病史', `family_history` varchar(255) DEFAULT NULL COMMENT '家族病史', `remark` varchar(500) DEFAULT NULL COMMENT '备注', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `deleted` tinyint(1) DEFAULT '0' COMMENT '逻辑删除标识', PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有几个设计细节值得注意。第一，user_id一定要建索引，因为所有针对某个人的档案查询都要走这个字段。第二，deleted字段用逻辑删除，避免用户删除档案后相关历史记录彻底丢失。这在医疗健康类系统中是合理的设计思路。第三，身高体重用decimal而不是int，因为身高可能有 168.5 这种数据。
需要一张关联查询示例图的话，我口头描述一下逻辑关系。health_profile.user_id指向sys_user.id，health_record.user_id也指向sys_user.id，service_appointment.user_id指向用户、service_appointment.item_id指向service_item.id。这就是典型的一对多和一对一关系。
3.3 需要注意的数据库设计细节
有几个坑我在实际开发中踩过，提前写出来。
第一，所有表都要有create_time和update_time，这是非常基础但重要的规范。用 MyBatis-Plus 的话可以直接配置字段自动填充，不需要每次手动塞时间。
第二，varchar 长度要按实际业务设置。手机号码 11 位，姓名 50 个字符足够，但身份证号不要直接用 varchar(18)，因为最后一位可能带 X，你要预留长度同时加上校验。不过身份证明文存储不太合规，课设为了方便可以存，但论文里最好提一句生产环境应加密存储。
第三，也是很容易踩的坑：如果开了逻辑删除，同时又给某个字段建了唯一索引，逻辑删除的数据会占用这个唯一键。比如账号字段如果加了唯一索引，用户被逻辑删除后账号还在表里，再注册同名账号就会被拦截。解决方法是唯一索引改成联合索引，加上deleted字段，或者删除时给账号字段拼一个时间戳后缀。
4. 核心功能模块剖析：关键代码是怎么写的
4.1 登录鉴权与权限控制
登录鉴权这块，我用的方案是 Spring Security + JWT。整体流程是：用户提交用户名密码，后端校验成功后生成 JWT token 返回前端，前端后续请求在 Header 里带上Authorization: Bearer token，后端通过过滤器解析 token 并设置登录用户上下文。
关键配置类：
@Configuration @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .authorizeRequests() .antMatchers("/api/auth/login", "/api/auth/register", "/static/**").permitAll() .antMatchers("/api/admin/**").hasRole("ADMIN") .antMatchers("/api/staff/**").hasAnyRole("ADMIN", "STAFF") .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); } }使用 Spring Security 的关键点是理解过滤器的执行顺序。我自己的JwtAuthenticationFilter必须在UsernamePasswordAuthenticationFilter之前执行，因为要先解析 token 并把Authentication对象放到 SecurityContext 中，后面的权限判断才能拿到用户角色。
很多课设项目用简单的拦截器加 Session 也能实现登录，我为什么推荐 Spring Security？因为论文里可以写“基于 Spring Security 的认证与授权机制，有效防止越权访问”，这句话的含金量比“用拦截器判断是否登录”高不少。同时你也在真实提升自己的框架理解能力。
4.2 健康档案与测量记录模块
健康档案模块就是典型的单表 CRUD，但有一点值得讲：档案和测量记录之间的展示关系。前端页面展示档案时，我不会简单地只查档案表，而是把最近一次的健康测量记录一起带出来，让老人或服务人员一眼看到当前的健康趋势。
代码实现上，可以用 MyBatis-Plus 的 ServiceImpl 减少重复代码。比如健康档案保存逻辑：
@Override public Boolean saveProfile(HealthProfileDTO dto) { LambdaQueryWrapper<HealthProfile> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(HealthProfile::getUserId, dto.getUserId()); HealthProfile existing = this.getOne(wrapper); if (existing != null) { BeanUtils.copyProperties(dto, existing); return this.updateById(existing); } HealthProfile profile = new HealthProfile(); BeanUtils.copyProperties(dto, profile); return this.save(profile); }这里用到一个小技巧：同一个用户只能有一条健康档案，所以新增的时候先查是否存在。存在就更新，不存在就新增。这样前端不需要区分“新增档案”和“编辑档案”两个页面，逻辑更统一。
健康测量记录模块的核心是分页查询和趋势展示。分页用 MyBatis-Plus 自带的分页插件，前端传页码和每页条数，后端返回总条数和列表数据。展示趋势的时候，把最近 7 天的血压数据从数据库查出来，转换成年月日格式的列表，交给前端 ECharts 画折线图。
4.3 服务预约模块的状态流转
服务预约是整个系统里最有业务感的模块，因为它涉及状态的流转。我用一个 int 类型的 status 字段来表示：
| 状态值 | 含义 | 前端显示 |
|---|---|---|
| 0 | 待确认 | 待确认 |
| 1 | 已确认 | 服务人员已接单 |
| 2 | 已完成 | 已完成 |
| 3 | 已取消 | 已取消 |
状态流转规则要写清楚：用户提交预约后为待确认；服务人员确认后变为已确认；服务执行完成后变为已完成；用户在待确认或已确认状态下可以取消。已完成的不能取消。这个规则直接在 Service 层判断：
public Result<String> cancelAppointment(Long appointmentId, Long userId) { ServiceAppointment appointment = this.getById(appointmentId); if (appointment == null) { return Result.error("预约不存在"); } if (appointment.getStatus() == 2) { return Result.error("已完成的服务不能取消"); } if (appointment.getStatus() == 0 || appointment.getStatus() == 1) { appointment.setStatus(3); this.updateById(appointment); return Result.success("取消成功"); } return Result.error("当前状态不允许取消"); }这就是状态机在业务里的简化应用。答辩时你可以说：用状态字段控制整个预约生命周期，通过在 Service 层校验当前状态来避免非法操作。这个设计点很小，但能体现你的业务逻辑思考能力。
4.4 统计报表怎么从数据库出数据
统计报表听着高大上，其实核心就是几个 SQL 聚合查询。最常见的是按日期统计预约数量，SQL 长这样：
SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS date, COUNT(*) AS total FROM service_appointment WHERE create_time >= #{startDate} AND create_time <= #{endDate} GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d') ORDER BY date这里有一个重点，不能直接在 MySQL 里对 create_time 用%Y-%m-%d格式化后再 group by，性能会差。但课设数据量不到一万条，这种写法完全够用，反而简单直观。更好的写法是用create_time >= ? AND create_time < DATE_ADD(?, INTERVAL 1 DAY)这样的范围查询，旁边再按字段分组，不过复杂度会上去。
统计模块我建议做一个“首页数据看板”，展示四块内容：总用户数、今日预约数、本月新增档案数、近7天预约趋势。数据看板一眼就能让答辩老师看出系统的完整性，也是截图放进论文里的好素材。
5. 源码导入与数据库初始化：从零跑通项目
5.1 环境准备
拿到源码后别急着双击打开，先把环境准备好。我推荐的环境版本如下：
| 软件 | 推荐版本 |
|---|---|
| JDK | 1.8 |
| Maven | 3.6.3 或 3.8.x |
| MySQL | 5.7 或 8.0 |
| IDEA | 2021 以上即可 |
| Lombok 插件 | IDEA 自带或手动安装 |
JDK 版本为什么推荐 1.8？因为这个项目的 Spring Boot 版本是 2.7.x，对 JDK8 支持最好。你要是装了 JDK17 甚至 JDK21，反而可能出现兼容问题。不少同学第一次跑不起来，就是 IDEA 里 Project SDK 选错了版本。
MySQL 建议用 8.0，因为 8.0 的驱动类和 URL 写法跟 5.7 有区别。你拿到的源码如果用的是com.mysql.cj.jdbc.Driver，就说明是针对 MySQL 8 写的，不要拿着去跑 5.6 的旧库。
5.2 导入项目与初始化数据库
导入项目有两条路，我用 IDEA 演示最常规的一条。
第一步，IDEA 中选File -> New -> Project from Existing Sources，找到源码根目录的pom.xml，以 Maven 项目方式导入。导入后等右下角的 Maven 依赖下载完成。如果下载慢，参考后面的常见问题部分换镜像源。
第二步，在 MySQL 中建库。打开 Navicat 或命令行，执行：
CREATE DATABASE community_health DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;注意，数据库名不要随便换成别的，除非你同步修改application.yml里的连接配置。建库后，选择这个库，运行源码中sql目录下的初始化脚本，一般在sql/community_health.sql。运行完后你应该能在表列表里看到 sys_user、health_profile 这些表。
第三步，检查启动配置。打开application.yml，核对三件事：数据库名、用户名、密码。这三个是最容易漏改的，也是启动报错最常见的原因。
5.3 关键配置与启动验证
启动项目前，application.yml 里最核心的数据源配置是这个样子：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/community_health?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 type: com.alibaba.druid.pool.DruidDataSource mybatis-plus: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.community.health.entity global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0启动主类后，控制台出现 Spring Boot 的 Banner，接着看到一行Tomcat started on port(s): 8080，就说明启动成功了。
然后浏览器访问http://localhost:8080/，如果跳转到登录页，说明前端资源和页面加载正常。默认账号密码在文档里一般会写清楚，通常是admin / admin123之类。如果登录后页面报 500，优先检查数据库密码和账号是否写对。
另外一个小细节：Thymeleaf 页面改动后需要刷新浏览器，但如果你改了 Java 代码却不想重启项目，可以在 IDEA 里配 Spring Boot DevTools 热部署。不需要专门重启，终端不停，页面也会自动刷新，调试体验好很多。
6. 常见问题与排障技巧实录
6.1 应用启动类问题
启动时最容易碰到两类报错：一类是“端口被占用”，另一类是“找不到主类或依赖冲突”。
端口被占用时，控制台会提示Port 8080 was already in use。解决办法：改配置文件里的server.port，改为 8081 或 9090。也可以直接把占用进程结束。Windows 上用netstat -ano | findstr 8080找到 PID，然后taskkill /pid PID /f；Mac 或 Linux 上用lsof -i:8080。
依赖冲突的问题通常表现为某个类找不到或者方法报 NoSuchMethodError。这种情况多半是引入了多个版本的同一依赖。我的经验是检查pom.xml，去掉重复依赖，或者用mvn dependency:tree查看依赖树。
6.2 数据库连接问题
数据库连接报错是重灾区，最常见的几种错误信息我整理成了表格，方便你们直接对照排查：
| 报错信息 | 原因 | 解决办法 |
|---|---|---|
Access denied for user 'root'@'localhost' | 用户名或密码错误 | 修改 application.yml 中的账号密码 |
Unknown database 'community_health' | 数据库不存在或名字写错 | 检查 SQL 脚本是否执行成功 |
Server returns invalid timezone | 时区配置问题 | URL 加serverTimezone=Asia/Shanghai |
Public Key Retrieval is not allowed | MySQL 8 驱动认证问题 | URL 加allowPublicKeyRetrieval=true |
Connection refused | 数据库没启动 | 打开 MySQL 服务，确认端口为 3306 |
最坑的是Public Key Retrieval is not allowed。MySQL 8 默认用 caching_sha2_password 认证，JDBC 驱动第一次连接时无法直接获取公钥，就会报这个错。解决方式就是在连接串上补一个参数allowPublicKeyRetrieval=true。
6.3 Maven 依赖下载与编译问题
Maven 如果下载特别慢，根本原因是没有配置国内镜像。IDEA 中打开settings.xml，在 mirrors 节点里加阿里云仓库：
<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>改完镜像源后，IDEA 里Ctrl+Shift+F10或点刷新 Maven 项目，重新下载即可。Compilation 报错如果指向 Lombok 的注解，比如getter/setter 找不到，多半是 IDEA 没有启用注解处理器。在 IDEA 的Settings -> Build, Execution, Deployment -> Compiler -> Annotation Processors里勾选Enable annotation processing，重启项目就好。
6.4 功能层面的奇怪 Bug
页面能打开但登录后跳到 404，多半是因为前端访问的路径跟 Controller 里的映射不一致。比如控制器映射是/admin/index，但页面里的链接写成了/admin/index.html。Thymeleaf 是模板引擎，不是静态资源，不需要后缀，路径要对齐。
还有一类问题比较隐蔽：用了逻辑删除后，一查数据就查不到。如果你自己写 SQL 时忘记加where deleted = 0，MyBatis-Plus 自动生成的查询都会带上，但手写的 XML 不会。这就导致有些页面正常，有些页面却看不到同一条记录。解决办法是自定义 XML 里的查询统一拼接deleted = 0条件。
还有，如果你改过表结构，比如新增了字段，但实体类里没加对应属性，MyBatis-Plus 查询时结果集映射会忽略这个字段，页面取数据时自然就是 null。新增字段后，注意同步实体类中的属性。
结尾的个人收尾
这套系统完整跑下来，我个人最大的感受是：课设和毕设项目，功能多不如功能精。很多人一上来想做强杀、秒杀、高并发，结果数据库表建了二十多张，功能却都是半成品，论文写得云里雾里。社区康养管理系统最大的优点就是业务链路完整，每个模块能讲出设计理由，代码量适中，框架技术也拿得出手。
如果你时间充裕，可以在此基础上加一个体检报告导入导出、或者家属端分离的页面，再补几张数据权限控制的图，论文的实用性和完整度会上一个台阶。答辩前建议自己完整跑两遍演示流程，把管理员新增用户、用户预约服务、服务人员处理预约、管理员查看统计报表这四个主流程连起来走一遍，记得准备几条不同状态的预约数据，免得现场临时造数据手忙脚乱。祝你们顺利。
