Spring Boot社区养老服务平台：从选题到答辩全流程指南-平芜编程栈

每到毕业设计季，选 Java 方向的同学总会跟这几个词反复打照面：springboot、社区养老服务平台。说实话，这个题目的热度在我带过的小组里已经连续几年排前三，原因很简单：它不像那些要算法要模型的题目那么硬核，但也远不是填个静态页就能交差的东西。做这个项目，你需要真正把“老人档案、服务工单、健康数据、活动管理”这些业务串起来，做成一个能登录、能干活、能出报表的系统。

这篇文章就围绕 springboot 社区养老服务平台的设计与实现，把选题逻辑、技术选型、数据库设计、核心代码、部署运行、论文答辩这条完整链路拆开讲一遍。不管你是正在纠结要不要选这个题，还是已经写完八千字论文但系统还在报错，这篇文章都值得照着一步步来。

1. 这个题目的真实定位：养老平台是业务驱动的 CRUD 项目

先破个冷水：社区养老服务平台从技术层面看，本质是一个标准的业务管理系统，日常操作就是增删改查，最多叠加上传文件、统计图表、消息提醒。但别因为这个定位就觉得没东西可写——毕设的分数恰恰来自“业务闭环做得多完整”，而不是“用了多新潮的框架”。

这类系统一般围绕三条主线：

老人信息管理：从录入档案、健康数据登记，到家庭成员绑定，这是后续所有服务的数据底座。
服务工单流转：家属或老人发起助餐、助洁、助医等预约，管理员调度服务人员接单，完成后回填记录并评价。
社区运营管理：活动发布、通知公告、服务人员排班，以及面向管理者的统计报表。

明白这三条线，再看 springboot 就清楚多了：springboot 在这里起到的作用是快速拉起一个稳定可运行的后端服务，把 MVC 分层、依赖装配、内嵌服务器这些底层的活都干完，你只需要专注于写业务接口。对于要做毕业设计的同学，这意味着你不需要从 Tomcat 配置、Spring 容器的繁琐 XML 里挣扎出来，省下来的时间可以投在真正拉分的业务功能和界面打磨上。

适合什么人？想稳妥毕业、对 Java 后端有一定基础但不追求高难算法的同学；已经学过 springboot 基础，但对整合 MyBatis、写权限控制心里没底的同学；以及希望这个系统在答辩时能现场“跑给你看”的同学。

我还想多提一句：你把题目里“社区养老服务平台”这几个字换成“物业管理系统”“健身房管理系统”“志愿者服务平台”，核心架构其实是同一套。选这个题的价值就在于，它给了你一个足够真实、有社会意义的业务场景，做出来的东西不至于让人觉得是玩具。

2. 技术选型：springboot 版本别追新，选型要能自圆其说

这一节讲为什么是这套技术栈，以及每一环怎么选才算聪明。

2.1 springboot 版本和 JDK 版本怎么匹配

网上大量资料、博主、学长遗留代码都是基于 JDK 8 + Spring Boot 2.x 的。所以我给的建议是：JDK 8 配 Spring Boot 2.7.18，这是 2.x 的最后一个版本，稳定性和资料覆盖度都最好。

不要为了新鲜感上 Spring Boot 3.x，它要求 JDK 17+，很多第三方 starter 的兼容版本需要额外排查，对毕设来说纯属给自己加戏。真到答辩环节，老师问“为什么不用最新版”，你可以答：企业生产环境里大量存量项目仍以 2.x 为主，选它保证生态兼容性和团队维护成本最低——这个回答比“我懒得升级”体面得多。

2.2 持久层选 MyBatis-Plus，而不是裸 MyBatis

如果你用原生 MyBatis，每个实体都要写 Mapper 接口、XML、对应的 SQL 增删改查，一个老人档案表就够写十几屏。MyBatis-Plus 在 MyBatis 基础上内置了通用 CRUD、分页插件、逻辑删除、代码生成器，真正要手写 SQL 的地方只剩多表关联查询和报表统计。

我见过不少同学在这道题里选择 JPA，但说实话，中文社区和毕设参考代码里 MyBatis-Plus 占绝对主流，遇到问题搜答案最方便。选它不是因为最强，而是因为“整体成本最低”。

2.3 前端用 Vue 前后端分离，还是 Thymeleaf 非分离

两种方案我都带人做过，直接说判断标准：

目标只是快速把功能跑通、论文篇幅有限：用 Thymeleaf 服务端渲染，springboot 一个工程搞定所有事，部署最简单。
想给自己的简历和答辩加分、愿意多花时间：用 Vue3 + Element Plus + Axios 做前后端分离，后端出 RESTful API，前端单独工程部署。

我自己比较推荐后者，因为“springboot + vue前后端分离”几乎是当前 Java 招聘 JD 里的标配词。哪怕你只是把登录页、老人管理页、工单管理页做成前端工程，也算有完整的现代 Web 开发体验。

2.4 数据库和可选中间件

数据库无脑选 MySQL 8.x，JDBC URL 里记得带上这些参数：

url: jdbc:mysql://localhost:3306/community_care?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

characterEncoding 解决中文乱码，serverTimezone 解决 LocalDateTime 和 MySQL 的 8 小时时区差问题。

Redis 和 MinIO 这类中间件属于“加分项但非必须”。如果要做验证码登录、热数据缓存，可以上 Redis；如果要做老人照片、活动图片上传而不是存本地磁盘，可以上 MinIO。但一定记住：新技术每加一个，答辩时就多一个可能被深挖的靶子，优先把主流程打磨干净，再谈中间件。关于热词里的“金仓读写分离”，那是国产化数据库场景才考虑的内容，除非学校明确要求对接金仓，否则毕设项目用 MySQL 完全够了。

提示：技术选型不是越新越好，而是每一步都要能在论文“可行性分析”里写出理由。老师很吃这一套。

3. 功能模块拆解与数据库设计，项目成败看这里

很多人写毕设一上来就写代码，写到一半发现表结构缺这个缺那个，返工成本极高。实际上这个题目的核心工程是“把表设计好”，表对了，业务代码是被带出来的。

3.1 角色与功能地图

系统建议分三种角色，不要多，多了撑不住：

管理员：维护老人档案、审核服务人员、管理工单状态、发布活动和公告、查看统计报表。
服务人员（护理员/志愿者）：查看被指派的工单、上报服务完成情况、录入老人健康监测数据。
老人/家属：浏览服务项目、提交服务预约、查看服务记录和健康提醒。

围绕这三类角色，功能模块可以这样划分：

模块	核心功能	主要参与角色
登录与权限	账号密码登录、角色鉴权、密码加密	全部
老人档案	基本信息、家属联系方式、历史服务记录	管理员、服务人员
服务工单	预约、派单、接单、完成、评价	全部
健康管理	血压、心率、血糖等数据录入与趋势展示	服务人员、家属查看
活动与公告	社区活动发布、报名、通知展示	管理员、老人/家属
数据统计	服务量统计、老人健康异常统计、人员工作量排名	管理员

3.2 核心表结构设计

最少需要这些表：user（登录账号）、role（角色）、older_person（老人档案）、service_worker（服务人员）、service_order（服务工单）、health_record（健康记录）、activity（活动）、notice（公告）。

给出前两张核心表的建表 SQL，供参考：

CREATE TABLE `older_person` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '老人姓名', `gender` tinyint DEFAULT NULL COMMENT '1男 2女', `birthday` date DEFAULT NULL COMMENT '出生日期', `phone` varchar(20) DEFAULT NULL COMMENT '联系电话', `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号', `address` varchar(255) DEFAULT NULL COMMENT '居住地址', `health_status` varchar(255) DEFAULT NULL COMMENT '健康概况', `family_phone` varchar(20) DEFAULT NULL COMMENT '家属电话', `deleted` tinyint DEFAULT 0 COMMENT '逻辑删除标记', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='老人档案表'; CREATE TABLE `service_order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '工单编号', `older_id` bigint NOT NULL COMMENT '老人ID', `worker_id` bigint DEFAULT NULL COMMENT '服务人员ID', `service_type` varchar(20) DEFAULT NULL COMMENT '服务类型：助餐/助洁/助医/代办', `appoint_time` datetime DEFAULT NULL COMMENT '预约时间', `status` tinyint DEFAULT 0 COMMENT '0待接单 1服务中 2已完成 3已取消', `content` varchar(500) DEFAULT NULL COMMENT '服务内容描述', `score` tinyint DEFAULT NULL COMMENT '评价分数1-5', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='服务工单表';

几个设计经验：

外键：毕设项目强烈建议用逻辑外键，也就是只在业务层面维护 older_id 指向 older_person 的关系，不建物理外键。否则后期测试数据清理、历史数据迁移会非常痛苦。
状态字段：status 用 tinyint 存数字状态，0、1、2、3 要在代码里写成枚举常量，不要散落着魔法数字。
逻辑删除：MyBatis-Plus 的 @TableLogic 可以实现“删了但没真删”，论文里写数据审计时会非常好看，而且确实实用。
所有时间字段用 datetime 类型，Java 侧用 LocalDateTime，避免用 Date 后出现各种格式化问题。

3.3 兜底清单：没想清楚这几点，后面必返工

一个老人可对应多个服务工单，但服务人员的接单上限要不要限制？建议在业务层查一下当天未完成工单数。
家属账号和老人档案的关系，建议在 user 表里加一个 older_id 字段或者单独建关系表。毕设场景前者更简单。
健康记录表要按老人 ID + 时间建索引，否则数据一多，报表查询会变慢。
工单编号不要用自增 ID 直接暴露给用户，建议用“时间戳 + 随机数”生成一个唯一 order_no，看起来正规，也方便后续对接支付或短信通知。

4. 核心流程落地：从服务预约到工单闭环

4.1 项目包结构与分层

我推荐一个很传统的分层，也是答辩老师最熟悉的结构：

com.community.care ├── controller // 接口层，只做参数接收和结果封装 ├── service // 业务逻辑层 │ └── impl ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 实体类 ├── dto // 入参对象，避免直接用实体接收前端参数 ├── vo // 出参对象，按页面需求裁剪字段 ├── config // 配置类：分页插件、拦截器、跨域等 └── common // 统一返回结果、异常处理、常量等

为什么不让 controller 直接干业务？因为答辩和以后写代码都一样，controller 一旦膨胀，接口参数变动会导致所有调用方跟着改。用 dto 和 vo 把边界画清楚，是体现工程素养最便宜的方式。

4.2 下单核心代码：状态流转与事务

服务预约流程是系统的“心脏”。前端提交预约后，后端要生成工单编号、默认状态置为“待接单”，然后管理员或系统按规则派单。ServiceImpl 的核心代码大致是这个样子：

@Override @Transactional(rollbackFor = Exception.class) public boolean createOrder(ServiceOrderCreateDTO dto) { ServiceOrder order = new ServiceOrder(); order.setOrderNo(generateOrderNo()); order.setOlderId(dto.getOlderId()); order.setWorkerId(dto.getWorkerId()); order.setServiceType(dto.getServiceType()); order.setAppointTime(dto.getAppointTime()); order.setStatus(OrderStatus.PENDING.getCode()); order.setContent(dto.getContent()); return this.save(order); }

这里有两个要点值得展开：

@Transactional 已经把事务控制的姿势摆好了，insert 任何一步失败都能回滚，避免出现“工单编号生成了但订单没插入”的脏数据。
状态流转不要做得太复杂。很多教程会让你写一个状态机引擎，对毕设来说过度设计。用 ServiceImpl 里的几个 if 判断足够：PENDING 可以接单或取消，SERVICING 只能完成，COMPLETED 只能评价。把每个流转放到 service 方法里校验，而不是散落在 controller 各处。

4.3 工单列表的分页查询：最容易翻车的 MyBatis-Plus 坑

列表页十有八九要用分页，而 MyBatis-Plus 分页最大的坑是：不加分页插件，Page 对象也能查，但 total 永远返回 0。不少人调试到崩溃，其实只是忘了在配置类里注册拦截器：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

查询条件用 LambdaQueryWrapper 来做，可以避免手动字符串拼接 SQL 的注入风险：

public IPage<ServiceOrder> listOrders(int pageNum, int pageSize, Integer status, String keyword) { Page<ServiceOrder> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<ServiceOrder> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(status != null, ServiceOrder::getStatus, status); wrapper.like(StrUtil.isNotBlank(keyword), ServiceOrder::getOrderNo, keyword) .or().like(StrUtil.isNotBlank(keyword), ServiceOrder::getContent, keyword); return serviceOrderMapper.selectPage(page, wrapper); }

提示：eq、like 这类方法都有一个“第一个参数是 boolean”的重载，条件不成立就自动忽略限制，写条件查询特别舒服。列表接口务必统一返回 IPage 对象，前端表格组件能直接消费，不用自己拼页码。

4.4 健康数据模块：这个模块是论文里的“亮点位”

健康管理模块虽然也是一个 CRUD，但它是整个平台最贴近“养老”二字的模块，值得稍微用心一点。建议做成：服务人员上门时录入老人的血压、心率、血糖，系统自动判断是否超出阈值，超出则给家属端推送提醒（简单做法是生成一条未读消息记录，别一上来就搞 websocket）。数据要用趋势图展示，前端用 ECharts 拉一个接口返回近 30 天数据即可。这一段写进论文“系统实现”时，既有逻辑又有界面，老师印象分会拉满。

5. 权限设计：用 Spring Security 还是拦截器？

5.1 两种方案的取舍

关于权限，我不卖关子，直接说方案：

方案 A：Spring Security + JWT，适合你时间充裕、想在简历上写“熟悉 Spring Security”的同学。
方案 B：HandlerInterceptor + Redis/数据库 Session，适合求稳、想尽快跑通的同学。

坦白讲，这种三角色规模的系统用拦截器完全可行，而且更好讲。但如果你已经在用 Vue 前后端分离，我建议方案 A，因为 JWT 是面试高频考点，做一次毕设顺便把考点过一遍很划算。

5.2 认证与鉴权的最小实现

后端提供 /api/login 接口，校验用户名密码后生成 token，前端每次请求把 token 放在 Authorization 头里。密码必须用 BCryptPasswordEncoder 加密存储，这是老师必问项。

之后注册一个拦截器做鉴权，核心思路是：

// 在 preHandle 中解析 token，取出 userId 和 role // 存入 ThreadLocal，供后续业务代码读取当前登录人 // 白名单之外的请求如果没有 token 直接返回 401

防止越权操作还要再补一刀：状态变更接口都必须校验“当前操作人是否有权限操作这条工单”。比如服务人员只能完结指派给自己的工单，不能拿着别人的工单号来改状态。平时很多项目只做了登录，没做数据级权限，演示时一旦被老师现场换账号试出来就扣分严重，这是我最想强调的细节。

5.3 管理端统计报表的 SQL 思路

报表是管理员模块最容易出彩、也最容易写砸的地方。建议至少做两个：

服务人员工作量统计：按 worker_id 分组统计不同状态工单数量。
近 7 日服务量趋势：按 create_time 按天分组。

这类统计建议直接在 Mapper 里写@Select注解，返回一个 Map 或 VO 列表。SQL 思路很简单，但注意一个细节：按天分组时最好用DATE_FORMAT(create_time, '%Y-%m-%d')，否则时间精确到秒，永远分不成组。

6. 本地跑通与部署：IDEA 里最容易翻车的几个点

这一节的内容几乎是给“卡在第一步”的同学准备的，代码写再多，跑不起来等于零。

6.1 核心配置项 application.yml

下面这份配置基本是这类项目的标准模板：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/community_care?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 10MB mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true 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

如果遇到 MyBatis-Plus 3.x 版本接口不兼容，把 spring boot 版本稳定在 2.7.x、MyBatis-Plus 用 3.5.x 基本不会有大问题。版本组合这件事，绝对是这类项目最容易浪费时间的隐形坑，我见过太多人 debug 到半夜，最后发现是 starter 版本冲突。

6.2 数据库初始化与 IDEA 运行步骤

在 MySQL 里建库：CREATE DATABASE community_care DEFAULT CHARACTER SET utf8mb4;
把设计好的建表 SQL 按顺序执行，注意打开 SQL 文件时确认 IDEA 右下角编码是 UTF-8，否则中文注释全变乱码。
在 IDEA 里直接运行启动类，看到 Spring Boot 启动成功的日志后，浏览器访问http://localhost:8080。
若用前后端分离，前端工程在npm install后执行npm run dev，通过 Vite 默认端口访问，后端记得配 CORS。

这里有一个高频报错表，建议截图保存：

现象	常见原因	处理办法
Failed to configure a DataSource	数据源没配或被自动装配卡住	检查 yml 里的 url/username/password
分页 total 为 0	没注册分页插件	补 MybatisPlusInterceptor 配置
中文乱码	连接串没有 characterEncoding 或建表非 utf8mb4	统一 UTF-8
Mapper 方法找不到	启动类没加 @MapperScan	加注解或每个 Mapper 加 @Mapper
端口被占用	8080 被其他进程占用	换 server.port 或查进程
本地能跑，部署后上传文件丢失	使用了相对路径存储	配置绝对路径或改 MinIO 等对象存储

6.3 打包部署：不要只会在 IDEA 里跑

毕设现场演示一般用 IDEA，但你最好能把 jar 包也跑一遍，论文“部署说明”章节用得上：

mvn clean package -DskipTests java -jar target/community-care-0.0.1-SNAPSHOT.jar

Linux 服务器后台运行可以加nohup。很多同学不知道打包前要去掉spring-boot-maven-plugin里的某些 repackage 冲突，所以这里提醒一句：构建失败时优先看依赖树mvn dependency:tree，找红色冲突行，单独排除版本。

7. 论文怎么写、答辩怎么讲：这些设计能加分

7.1 论文结构和每个章节的写法

标准毕设论文一般至少包含：摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结。这些章节点对应的“工作量证据”很关键：

需求分析：画用例图，不要只画一个空壳，要把管理员、服务人员、老人/家属三个角色的用例全部画出来。
系统设计：架构图 + 功能模块图 + E-R 图 + 核心表结构说明，E-R 图是答辩老师扫得最快的一张图。
系统实现：每个重点功能给截图 + 核心代码片段 + 简要流程描述，切忌大段贴代码。
系统测试：功能测试用表格列测试用例，例如登录、工单流转、权限拦截、分页查询，每条写预期结果和实际结果是否一致。

7.2 老师最爱问的几个问题

我把这几年被问过最多的问题整理成一份清单，提前准备就不会慌：

为什么选择 Spring Boot？答：简化配置、内嵌服务器、生态丰富，是企业级开发的主流框架。
MyBatis-Plus 和 MyBatis 的区别是什么？答：Plus 提供通用 CRUD 和分页插件，但复杂 SQL 仍可写 XML，保留了灵活性和开发效率。
分页是怎么实现的？答：MyBatis-Plus 分页插件会在执行时自动改写 SQL，拼接 limit 参数。
密码安全怎么做的？答：BCrypt 加盐哈希存储，登录校验时比对哈希值。
不同角色的接口怎么区分权限？答：登录后 token 携带角色信息，拦截器统一校验接口需要的角色白名单。
遇到的最大困难是什么？答：建议讲一个真实排错案例，比如分页 total 为 0、时区乱码、跨域问题，重点讲排查思路而不是抱怨。

7.3 一点个人体会

带这个题目的同学带得多以后，我的感觉是：最后拿高分的，往往不是代码写得最炫的，而是演示流程设计最顺的。提前准备好几个真实账号，每个角色登录后按脚本走一遍：家属预约、管理员派单、服务人员完结、家属评价、管理员看报表。每一步都不要犹豫，工单状态每一步都能对应上数据库记录，这就是最好的“设计与实现”证据。哪怕代码里有些细节不完美，只要能讲清楚每一步为什么这样设计，老师一般都会给不错的分数。