毕业设计折腾社区居家养老系统，Spring Boot这套组合拳我是这么打的
又到了毕设季，后台天天有人问社区居家养老管理系统怎么做。说实话，这类题目在毕设里算得上是“卷中卷”，因为业务场景足够贴近生活，功能边界清楚，评委也容易理解，但真要做出亮点、拿到高分，又不是随便CRUD就能糊弄过去的。我前前后后带过几个学弟做这个题，自己也完整搭过一套基于Spring Boot的社区居家养老管理系统，从选题、建表到接口落地、答辩准备，一路踩坑无数。这篇文章就把整个思路、核心模块、踩过的坑和答辩时的高频问题一次性讲清楚，源码相关的实现细节也会拆开揉碎聊。
先给这个系统定个位：它不是给养老院用的，是给“居家养老”场景用的——老人在自己家里住，社区服务中心提供上门护理、送餐、健康监测、紧急求助这类服务。系统要管的，就是服务工单怎么流转、老人档案怎么维护、护工怎么接单、健康数据怎么采集预警、家属怎么远程查看。搞清楚这个业务边界，后面所有设计都不会跑偏。
1. 选题复盘：为什么社区居家养老管理系统是好做的毕设，也难在哪儿
1.1 业务复杂度刚好卡在“加分区间”
毕设选题最怕两种：一种是纯管理系统，比如图书管理、学生管理，功能就是增删改查，技术含量低，答辩时评委问两句就露馅；另一种是纯算法研究，比如深度学习图像识别，工程量大且容易跑不出结果。社区居家养老管理系统恰好卡在中间——它有清晰的业务主体（老人、护工、工单、健康数据），有真实的流程逻辑（工单派发、服务完成、回访评价），又有可以深挖的技术点（工作流、定时任务、消息推送、报表统计）。
以工单为例，一个最简单的上门护理工单要经历：家属或老人在小程序下单→系统派单给护工→护工接单并上门→服务完成拍照上传→家属确认→系统生成账单和评价。这中间涉及状态机、角色权限、文件上传、消息通知，任何一个环节展开都能写不少代码。评委看到的是“这个学生不是只会对着表做增删改查，而是真理解了业务闭环”。
1.2 技术栈天然匹配市场需求
Spring Boot做这类企业级Web应用太合适了。内置Tomcat、自动配置、起步依赖管理，能把开发重心放在业务逻辑而非环境搭建上。配合MyBatis-Plus做数据层、Redis做缓存、MySQL做持久化，再挂一个轻量级的权限框架（比如Sa-Token或Spring Security），这套组合在国内中小型项目中几乎是标配，毕业设计用它，答辩时“技术选型合理性”这一项基本不丢分。
需要说明的是，我见过不少同学纠结要不要上微服务、要不要加MQ、要不要引入Flowable工作流。就毕设而言，如果不是团队项目或有极强的性能需求，单体应用加模块化分层完全够用。过度设计反而会让答辩陷入“你为什么要用这个东西”的连环追问。Flowable在养老工单场景里可以用在“工单审批流转”环节，如果论文需要强调工作流能力，可以用简单场景接入（下文会讲怎么用），不需要跑完整的BPMN引擎。
2. 技术选型定稿：Spring Boot为核心，各组件怎么配合
2.1 分层架构与依赖管理
我最终采用的标准四层结构：Controller层（接口暴露）、Service层（业务逻辑）、Mapper层（数据访问）、Entity/DTO/VO层（数据模型）。前后端分离，前端用Vue2或Vue3 + Element UI（如果不想写前端，直接用Thymeleaf配AdminLTE模板也行，但建议前后端分离，因为答辩时可以拆开讲“跨域处理”和“接口鉴权”）。
核心依赖清单大致长这样：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency>MyBatis-Plus是省时利器，分页插件、自动填充（创建时间/更新时间）、逻辑删除都是开箱即用。但它也有个坑：默认的字段映射策略是驼峰转下划线，如果数据库字段命名不规范，查询结果会直接为空，后面我会单独讲。
2.2 为什么用Sa-Token而不是Spring Security
这个决定很多人不理解，我解释一下。Spring Security功能强大但配置繁琐，对毕设选手来说，光一个密码加密方式、过滤链顺序、会话管理就能折腾一周。Sa-Token是国产轻量级鉴权框架，登录、注销、权限认证、踢人下线都封装好了，学习成本极低，核心代码就几行：
// 登录时下发token StpUtil.login(userId); String token = StpUtil.getTokenValue(); // 接口校验登录 @SaCheckLogin // 角色校验（护工端接口） @SaCheckRole("worker")养老系统里有三种角色：管理员（社区工作人员）、护工、家属/老人，用Sa-Token的权限注解可以很干净地控制接口访问。答辩时如果评委问“你的权限控制是怎么做的”，你可以从RBAC模型讲到Sa-Token的拦截器原理，再对比Spring Security的设计差异，这一串讲下来，技术深度一下就上去了。
2.3 工作流选型：Flowable的轻量接入方式
Flowable在工单流转场景中确实能画流程图、自定义审批链，但完整引入BPMN引擎对毕设来说有点重。我的做法是：只在“服务工单状态流转”上做简化版本的工作流——用一张流程定义表加一张流程实例表，再配一个状态机工具类，手动控制状态的变更与权限校验。
这样做的好处是代码可控、逻辑透明，答辩时你可以直接说“我这个版本先用手写状态机保证核心流转，Flowable预留了扩展点”，既展示了业务实现能力，又体现了架构意识。如果论文硬性要求必须有流程引擎，再在“服务申请审批”这个单向流程里接Flowable的ProcessEngine，定义一个简单的BPMN流程（申请→审核→派单→完成），用RuntimeService启动流程实例，用TaskService完成节点任务，也是可行的。毕设重点在于把原理讲清楚，而不是把功能堆全。
3. 数据库设计：一张工单表能不能支撑整个业务闭环
3.1 核心表的划分逻辑
社区居家养老管理系统的主体是“人”和“事”。“人”包括老人（elder）、家属（family）、护工（worker）、管理员（admin），“事”包括工单（service_order）、健康数据（health_record）、服务项目（service_item）、评价（evaluation）、公告（notice）。另外还有两张关联表：老人-家属绑定关系表、护工-服务项目技能表。
我第一次设计时犯过“一张大表搞定所有”的错，把所有业务塞进一张表，查询时SQL写得像迷宫。后来重构为按业务域拆表，边界清晰了很多。给你看几张关键表的结构：
elder（老人档案表）：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| name | varchar | 姓名 |
| id_card | varchar | 身份证号 |
| address | varchar | 住址 |
| health_status | varchar | 健康概况（慢性病/过敏史） |
| level | tinyint | 护理等级（1自理/2半自理/3全护理） |
| family_id | bigint | 默认绑定的家属账号 |
| deleted | tinyint | 逻辑删除标记 |
service_order（工单表）：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| order_no | varchar | 工单编号（按日期生成） |
| elder_id | bigint | 老人ID |
| worker_id | bigint | 护工ID |
| item_id | bigint | 服务项目ID |
| status | tinyint | 0待接单/1已接单/2服务中/3待确认/4已完成/5已取消 |
| appoint_time | datetime | 预约服务时间 |
| finish_time | datetime | 实际完成时间 |
| photo_url | varchar | 服务完成照片 |
| remark | varchar | 备注 |
工单表是整个系统的“业务中轴”，几乎所有模块都跟它有交集。状态字段我用int存，不用字符串，因为int可以做范围判断，也方便前端映射。但要注意：状态值一旦定下来就别随便改，否则历史数据会混乱。我当时的做法是在系统常量类里统一管理：
public class OrderStatus { public static final int PENDING = 0; public static final int ACCEPTED = 1; public static final int SERVING = 2; public static final int WAIT_CONFIRM = 3; public static final int COMPLETED = 4; public static final int CANCELED = 5; }3.2 逻辑删除与唯一索引的坑
MyBatis-Plus的逻辑删除需要在配置里指定全局删除值，我最初没配置，直接导致deleted字段不生效，查询时把已删除的数据也查出来了。正确做法是在application.yml里加：
mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0还有一个隐蔽的坑：工单编号order_no要加唯一索引，但如果在逻辑删除场景下，某条工单被“删除”后再生成同一编号，会有冲突。解决办法是生成编号时带上时间戳或随机串，比如ORD + yyyyMMddHHmmss + 三位随机数，保证唯一性。
3.3 索引设计与慢查询预防
养老系统的数据量在毕设规模下不会特别大，但评委可能会问“数据量大了怎么办”。我在service_order表的elder_id、worker_id、status、appoint_time上建立了联合索引，具体是：
ALTER TABLE service_order ADD INDEX idx_elder_status_time (elder_id, status, appoint_time);这个索引能覆盖“查询某位老人的历史订单”和“按状态过滤待处理工单”两类高频查询。需要注意联合索引的最左前缀原则——查询条件里必须包含elder_id才能走索引，否则索引失效。这是面试级的问题，答辩被问到的概率不低。
4. 核心接口落地的完整链路：从工单派发到健康预警通知
4.1 登录鉴权与双端会话隔离
养老系统分管理端（Web后台）、护工端（小程序或App）、家属端（小程序）三个端。我用Sa-Token做单点登录，每个角色登录后获得不同token，登录接口通过SaLoginModel设置角色标识：
@PostMapping("/login") public R login(@RequestBody LoginDTO dto) { // 校验用户名密码 User user = userService.checkLogin(dto.getUsername(), dto.getPassword()); // 登录并指定设备类型，防止家属token调护工接口 StpUtil.login(user.getId(), new SaLoginModel().setDevice(dto.getDeviceType())); StpUtil.getSession().set("role", user.getRole()); return R.ok(StpUtil.getTokenInfo()); }这里有个容易出细节分的点：接口层面除了校验登录状态，还要校验数据归属。比如家属A只能查自己绑定的老人数据，不能查别人家的。不能只在按钮上做权限控制，接口里必须做归属校验，否则就是越权漏洞。我给所有家属端查询接口加了currentFamilyId与目标elderId的绑定校验：
// 校验当前登录家属是否绑定该老人 boolean bound = elderFamilyService.checkBound(StpUtil.getLoginIdAsLong(), elderId); if (!bound) { throw new BusinessException("无权访问该老人的信息"); }4.2 工单状态机的接口设计
工单流转是整个系统最核心的接口。状态机本身不复杂，但每一步的状态变更都要同时触发额外动作：变更记录、消息通知、日志记录。我设计了一个OrderStateMachine组件，集中管理状态流转合法性：
@Component public class OrderStateMachine { private static final Map<Integer, List<Integer>> TRANSITIONS = new HashMap<>(); static { // 待接单 -> 已接单 / 已取消 TRANSITIONS.put(OrderStatus.PENDING, Arrays.asList(OrderStatus.ACCEPTED, OrderStatus.CANCELED)); // 已接单 -> 服务中 / 已取消 TRANSITIONS.put(OrderStatus.ACCEPTED, Arrays.asList(OrderStatus.SERVING, OrderStatus.CANCELED)); // 服务中 -> 待确认 TRANSITIONS.put(OrderStatus.SERVING, Collections.singletonList(OrderStatus.WAIT_CONFIRM)); // 待确认 -> 已完成 TRANSITIONS.put(OrderStatus.WAIT_CONFIRM, Collections.singletonList(OrderStatus.COMPLETED)); } public void validate(int from, int to) { List<Integer> allowed = TRANSITIONS.get(from); if (allowed == null || !allowed.contains(to)) { throw new BusinessException("非法的状态流转: " + from + " -> " + to); } } }工单状态的每个动作都对应一个独立接口，比如接单接口、开始服务接口、完成服务接口。护工端调“完成服务”接口时，需要上传照片和多条服务明细，我用@Transactional保证照片记录和服务完成动作要么一起成功要么一起回滚：
@Transactional(rollbackFor = Exception.class) public void completeOrder(CompleteOrderDTO dto) { // 1. 校验状态是否允许流转 // 2. 更新工单状态和完成时间 // 3. 保存服务照片 // 4. 生成评价提醒（异步） // 5. 给家属推送服务完成通知 }步骤4和5用Spring的事件机制解耦是非常好的加分项。定义一个OrderCompletedEvent，在监听器里处理通知推送，主流程不用关心这些副作用逻辑。答辩时可以说实现了事件驱动，代码可维护性更高。
4.3 健康数据预警：定时任务 + Redis缓存方案
健康管理模块看似简单，其实是个核心亮点。老人的血压、血糖、心率数据可以由护工上门时录入，也可以由家属绑定智能设备后同步进来。系统要做的核心事情是：异常数值实时预警。
我的方案是：每次健康数据入库后，马上和该老人的预警阈值做比较，如果触发异常，就生成预警记录并推送消息给绑定家属。由于异常判断逻辑可能会频繁触发，我把每个老人的阈值配置缓存到Redis里，key设计为health:threshold:{elderId}，避免每次查询都打数据库。
定时任务的部分我用了Spring自带的@Scheduled做每日健康报告汇总——每天早上8点给家属推送前一天的老人健康概览。这个功能非常亮眼，代码也不复杂：
@Component @Slf4j public class HealthReportTask { @Scheduled(cron = "0 0 8 * * ?") public void sendDailyHealthReport() { List<Elder> elders = elderService.list(); for (Elder elder : elders) { // 查询昨日健康数据 // 生成摘要并通过消息服务推送 } } }这里要提醒一个细节：@Scheduled默认是单线程串行执行的，如果一个任务执行时间过长，会阻塞后续任务。毕设场景一般无所谓，但为了展示专业性，我加了@Async配合线程池配置，并设置了ThreadPoolTaskScheduler的线程数。这段代码在答辩时拿出来讲“并发任务调度”非常加分。
4.4 文件上传的本地存储策略
老人档案和服务照片需要上传功能。毕设阶段不建议接OSS或云存储，因为要配密钥，还要担心被刷流量。我的做法是本地磁盘存储，上传目录通过配置项指定，然后用一个WebMvcConfigurer将本地目录映射为静态资源URL：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }从安全角度说，实际部署时绝不能把上传目录直接暴露成静态资源，需要做权限校验。但毕设阶段做映射是可以接受的，答辩时被问到就可以说“生产环境会用对象存储或加鉴权网关，本地映射是为了演示方便”。上传接口要做文件类型和大小限制，这属于基本素养，加上就行。
5. 毕设开发中踩过的坑：排查过程与根因分析
5.1 字段映射不一致导致的空指针噩梦
这是我第一次跑通系统时遇到的最郁闷的坑。数据库字段叫elder_name，实体类属性叫elder_name，但MyBatis-Plus默认开启了驼峰映射，我实体类写的是elderName，两者不匹配，查询出来全是null。排查过程花了整整一个晚上，最后发现是数据库字段是elderName（有人用工具建表时给列名加了驼峰），而MyBatis-Plus默认配置map-underscore-to-camel-case=true，只认下划线转驼峰，不认原样驼峰。
解决方法是统一规范：数据库列名全部用下划线elder_name，实体类用驼峰elderName，然后在application.yml里保持map-underscore-to-camel-case: true。这个问题的排查路径是：先打SQL日志看MyBatis实际执行了什么，再把查询结果用System.out打印，逐个字段核对，最后定位到映射关系上。
5.2 时间格式化造成的接口返回值错乱
前端传2025-06-01 10:00:00，后端实体类的LocalDateTime接收没问题，但返回给前端时默认序列化成了一个数组形式[2025,6,1,10,0,0]，前端解析直接报错。这个坑几乎每个做前后端分离的人都踩过。解决方式是全局配置Jackson的时间格式化：
@Configuration public class JacksonConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() { return builder -> { builder.simpleDateFormat("yyyy-MM-dd HH:mm:ss"); builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); }; } }更省事的方式是在application.yml里加spring.jackson.date-format，但那只对java.util.Date生效，对LocalDateTime无效，必须单独配序列化器。这也是个很容易被问的知识点。
5.3 Redis缓存穿透与空值缓存
工单列表做了Redis缓存，我最初只想到缓存查询结果，但某次测试时发现：查询一个不存在的工单ID，每次都会穿透到数据库，而且由于没有缓存空值，大量不存在ID的访问能把数据库打死。这是经典的缓存穿透问题。
解决手段有两个：一是缓存空值，二是布隆过滤器。毕设阶段我用的是缓存空值方案——查不到就缓存一个空对象，设置较短的过期时间（比如60秒）：
public ServiceOrder getOrderById(Long id) { String key = "order:" + id; Object cacheValue = redisUtil.get(key); if (cacheValue != null) { if ("EMPTY".equals(cacheValue.toString())) { return null; } return JSON.parseObject(cacheValue.toString(), ServiceOrder.class); } ServiceOrder order = orderMapper.selectById(id); if (order == null) { redisUtil.set(key, "EMPTY", 60); return null; } redisUtil.set(key, JSON.toJSONString(order), 3600); return order; }代码看似简单，但背后体现的是对缓存三兄弟（穿透、击穿、雪崩）的理解。答辩时把这个代码讲清楚，并顺带提一嘴“击穿可以用互斥锁解决，雪崩可以用随机过期时间解决”，技术深度直接拉满。
5.4 跨域问题导致接口联调失败
前端跑在localhost:8081，后端跑在localhost:8080，接口调用直接被浏览器拦截，报CORS错误。这个问题我一开始想不到，后来查了才发现是前后端端口不同导致的跨域。解决方式是在后端加一个全局CORS配置：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }注意：如果用了Sa-Token，跨域时OPTIONS预检请求不能要求登录，否则预检失败。需要在拦截器里放行OPTIONS请求，或者在CORS配置里处理。这个细节在联调时会坑你半小时，提前写进代码里能省很多事。
6. 答辩前夜：面试官最容易追问的十个问题
6.1 业务层面的追问怎么接
问题一：“你的系统跟普通的管理系统有什么区别？”答：核心区别在于业务对象是老年人群体，系统里融入了健康指标预警、工单派发流转、家属远程查看、紧急联系人通知等场景化功能。另外可以强调护理等级的动态调整逻辑——比如老人身体状况变差时，护理等级从“半自理”升为“全护理”，工单的计费和服务内容都会联动变化。
问题二：“如果护工数量不够，怎么处理高峰期的工单？”答：可以在系统里加一个“紧急调度”模块——当工单超过N分钟未被接单时，自动向所有符合技能要求的护工推送提醒，同时管理员可以手动强制指派。这个逻辑可以在工单表上加一个dispatch_status字段，配合定时扫描待接单工单实现。
问题三：“健康数据的准确性怎么保证？”答：两条路径——人工录入时做格式校验和范围校验（比如血压舒张压不能超过200），智能设备接入时预留数据校验接口，非法数据直接丢弃并记录日志。展示时可以写出具体的校验规则代码。
6.2 技术层面的追问怎么接
问题四：“为什么选MySQL而不是Oracle或PostgreSQL？”答：MySQL在小规模应用场景下性能足够、生态成熟、学习资料多，加上InnoDB支持事务和行级锁，对毕设这种规模的应用完全够用。可以补充的是MySQL 8.0支持窗口函数和CTE，做排行统计时很方便。
问题五：“Spring Boot的自动配置原理是什么？”答：核心在@EnableAutoConfiguration注解，它通过META-INF/spring.factories或AutoConfiguration.imports加载大量xxxAutoConfiguration类，这些类用@ConditionalOnClass、@ConditionalOnMissingBean等条件注解按需装配Bean。比如RedisAutoConfiguration只有在classpath下存在RedisOperations时才生效。
问题六：“介绍一下RBAC权限模型以及你的实现方式。”答：用户-角色-权限三张核心表，用户表关联角色表，角色表关联权限表。查询时先拿到用户角色，再汇总角色拥有的权限码。实现上我用Sa-Token接口加@SaCheckPermission("order:add")这类注解完成权限校验，管理员在系统里给角色分配权限码。答辩时可以现场手写三张表和嵌套查询的SQL。
问题七：“多端登录场景下token的过期策略怎么设计？”答：家属端token有效期7天，护工端12小时，管理端4小时。过期后强制重新登录。这个用Sa-Token的SaLoginModel.setTimeout()参数就可以控制，不同角色登录时设置不同有效期。
6.3 方向拓展类的追问怎么接
问题八：“如果系统要接入物联网设备，架构上要怎么改？”答：最直接的方式是在现有Spring Boot应用外挂一个MQTT Broker，智能手环通过MQTT协议上报数据，后端写一个MQTT订阅者服务消费数据，写入数据库并触发预警逻辑。设备数据量大时，可以在订阅者服务加消息队列缓冲，实现削峰填谷。
问题九：“怎么保证系统7x24小时稳定运行？”答：应用层面做到优雅停机、统一异常处理、日志监控；数据层面做到MySQL定时备份；部署层面可以用Docker Compose编排应用和MySQL、Redis，再用Nginx做反向代理。毕设能把Docker部署的流程演示清楚，就已经超过绝大多数人了。
问题十：“这个系统还有哪些可以优化的点？”答：可以加消息推送（对接微信模板消息）、可以加数据大屏（展示工单趋势、老人分布、健康预警统计）、可以把健康数据接入趋势分析图表，还可以用Spring Boot Admin做应用监控。挑一两个展开说，展示你的扩展思路。
7. 源码交付与二次开发的实用建议
拿到附带的源码后，别急着跑起来。先做三件事：第一，把application.yml里的数据库账号密码改成自己的，创建好数据库并导入SQL脚本；第二，确认Redis已启动，否则登录功能会因为Sa-Token依赖Redis而报错；第三，按下F5跑起来之后，先看控制台有没有报错，再看前端页面能不能正常请求到后端。
我第一次帮学弟排查跑不起来的问题时，十有八九是Redis没安装，或者MySQL版本和驱动不匹配。这里建议直接用MySQL 8.0 + Spring Boot 2.7.x，这个组合最稳。如果用Spring Boot 3.x，JDK要求17以上，而且Sa-Token的starter包名和兼容性有区别，需要额外注意。
二次开发我建议从这几块入手：一是给工单模块加一个日历视图，让管理员能直观看到每天的服务排期；二是给健康数据加趋势图，前端用ECharts，后端提供一个按老人ID和时间范围聚合统计的接口；三是增加数据导出功能，用EasyExcel把工单列表、老人档案导出成Excel。这三个方向改动量适中，演示效果好，答辩时还能顺势说“代码可复用、易扩展”。
另外提醒一点：源码里的注释和命名规范直接影响答辩印象分。拿到源码后，如果发现某些类名不符合规范（比如直接用拼音命名），自己花一天时间全量重构一遍，把常量提取、把重复代码抽成公共方法，这个过程本身就能让你对代码结构熟悉到能脱稿讲解。
社区居家养老管理系统这个题目的天花板并不低，关键看你怎么把业务故事讲圆、把技术细节讲透。把工单状态机、健康预警、权限控制这三条主线写明白，配合合理的缓存与定时任务设计，这套系统的完成度在毕设里已经算第一梯队了。我做这套东西最大的感受是：真正拉开差距的不是技术多炫，而是对业务场景的理解有多深——懂养老业务的人做出来的系统和只会写增删改查的人做出来的系统，一眼就能分辨出来。
