Spring Boot社区养老服务系统实战：从需求拆解到部署上线全复盘

我们团队接手“社区养老服务系统”这个项目时，第一反应不是打开IDEA敲代码，而是先去社区服务站蹲了两天。结果发现真实的场景远比想象中复杂：一位老人要预约上门送餐，服务站工作人员先接电话、再翻纸质台账、再用微信群问志愿者谁有空，最后还要手工登记服务结果。高峰期漏单、错单、重复派单几乎是家常便饭。

项目的本质很清晰：用基于Spring Boot的一套数字化系统，把社区养老服务的预约、派单、执行、回访、健康档案管理全部串成一条可追踪的业务闭环，让服务站从“靠人脑记忆”变成“有据可查”。本文从需求拆解、技术选型、核心模块实现、排错优化到上线部署，完整复盘这个系统的设计与实现过程。如果你正在做一个Spring Boot方向的实战项目，或者想了解一个业务系统从0到1落地的完整思路，这篇应该能给你不少参考。

1. 需求拆解阶段：先搞清“谁在用、谁在管、卡在哪”

1.1 社区养老服务场景的四个核心痛点

动工之前，我们和多个社区服务站的负责人聊过，最后把痛点收敛为四类，每一类都会直接影响系统功能设计：

这四个痛点的共性都是“信息不透明、流程不连续”。所以系统设计的核心目标不是做一个漂亮的界面堆功能，而是把每一类角色的操作都放进一个统一的流程框架里。举个例子，一次普通的送餐服务，线上至少要经历：家属或老人发起预约 → 服务站审核确认 → 系统按规则派单 → 服务人员接单 → 上门执行 → 现场电子确认 → 家属回访反馈。任何一步缺失，都会回到原来线下手工管理的混乱状态。

1.2 四类用户角色与核心业务闭环

系统用户最终划分为四类：

• 系统管理员：负责用户管理、服务项目配置、数据统计和系统参数维护；
• 服务站调度员：处理预约审核、派单、人工介入异常订单；
• 服务提供者：包括专业护工和社区志愿者，接受订单、更新服务进度、提交服务反馈；
• 老人及家属：发起预约、查看服务记录、接收健康预警通知。

这个设置看似常规，却有一个容易忽视的细节：老人本身大多不擅长操作智能手机，系统必须支持“家属代预约”“服务站代登记”两条替代路径。也就是说，预约入口不能只有登录后的App端，还需要一个允许工作人员快速代录的Web端表单。我们在设计时把“代录”作为一个独立的业务入口，页面字段与老人自助预约保持一致，后台生成相同的订单数据。这个决策在后来的试用反馈中得分最高，因为它没有改变服务站原有的工作习惯，只是把纸质登记换成线上录入。

业务闭环上，系统覆盖了“预约 → 派单 → 执行 → 确认 → 回访 → 归档”六个环节，外加一个贯穿始终的健康档案模块。健康档案不是独立存在的死数据，而是和服务记录联动：每次服务完成，系统会提示服务人员同步更新老人的状态描述和基础健康指标；当血压、血糖等指标超出预设的正常区间，或某一类服务长期未发生时，系统会触发预警。这样整个系统就不是一个单纯的“预约工具”，而是一个有观察、有反馈的养老服务管理平台。

2. 技术选型与数据模型：为什么这套组合最省心

2.1 锁定Spring Boot的决策过程

技术选型是一次很务实的权衡。后端候选方案有Spring Boot、Node.js、Python后端框架，我们最终选择Spring Boot，核心原因有三点：

第一，生态完整度。这个项目涉及认证授权、定时任务、文件上传、消息通知、数据持久化，Spring Boot几乎每一个方向都有成熟且文档充分的解决方案，不需要从零堆轮子。第二，团队维护成本。项目交付后通常由社区信息维护人员或后续实习生接手，Java圈的代码可读性和社区资料量明显占优，踩坑时搜答案的命中率高。第三，单体架构起步，演进不慌。Spring Boot天然支持从单模块快速拆分成多模块，前期就用标准的分层结构（Controller、Service、Mapper、Entity），后期即使要拆成微服务，改造路径也相对平滑。

具体技术组合如下：

我不想把技术选型说得太玄。这个项目体量并不大，选型的核心逻辑是“当前够用、维护方便、进阶有路”。比如用Redis不是为了展示技术，而是预约接口确实存在并发问题（后面会专门讲）；引入Spring Security也不是为了堆功能，而是四类角色之间的数据隔离必须有一个统一的鉴权入口。

2.2 核心表结构与两个关键设计决策

数据库共设计了十几张表，核心业务围绕三张主表展开：

• elder_info：老人档案，包括基本资料、紧急联系人、常用服务地址；
• service_order：服务订单，关联老人、服务项目、服务人员、状态和评价；
• health_record：健康记录，关联老人，保存每次健康指标数据。

以一个典型的订单表为例，核心字段包括：订单编号、老人ID、服务项目ID、服务人员ID、预约开始时间、预约结束时间、服务地址、状态（整型枚举：0待审核、1待派单、2待执行、3执行中、4已完成、5已取消、6异常）、备注、创建时间、更新时间。

这里有一个值得说的设计决策：订单状态用整型枚举而不是字符串。字符串看似直观，实际很容易因为拼写不一致产生脏数据（比如“Executing”和“executing”），而整型枚举配合统一的常量类，可以在编译期就规避掉大部分拼写错误，数据库索引对整型也更友好。

第二个决策是关于健康指标的存储方式。老人的健康指标包含血压、血糖、心率、体温等，但这些指标并不是固定的，今天可能新增血氧，明天可能关注尿酸。如果为每种指标单独建一列，后期扩展就得改表结构。我们的做法是：health_record主表只保存老人ID、记录时间、记录类型（上门测量/体检导入/自报）和备注，另外用一个JSON字段存指标键值对，MySQL 8.0对JSON字段的查询支持完全够用，程序里用Fastjson/Jackson解析就行。扩展新指标只改前端表单和一个小工具类，不需要动数据库结构。

索引规划上也花了一点心思。service_order表在运行一段时间后数据量增长很快，最频繁的查询是“某个老人近三个月的服务记录”和“某服务人员今天待执行的任务”，所以我们建了三个索引：idx_elder_time (elder_id, create_time)、idx_server_state (service_person_id, state)、idx_state_time (state, create_time)。亲测在十万级数据量下，这些查询基本都在几十毫秒以内，对于这个量级的系统完全够用。

3. 核心模块开发实录：从档案到订单的完整链路

3.1 老人健康档案的建模与录入实现

老人档案模块是整个系统的地基，预约、派单、健康预警都依赖准确的档案数据。实体类设计上，ElderInfo包含姓名、性别、出生日期、身份证号、联系电话、紧急联系人、紧急联系人电话、居住地址、有无慢性病史、用药情况、备注等字段。这里有个业务侧的要求：姓名和证件号在录入时必须与社区已有台账匹配，防止重复建档。所以我们给证件号码字段加了唯一索引，同时在录入接口里做了查重校验。

接口层面遵循Restful风格，核心的保存逻辑如下（简化版）：

@PostMapping("/elder") public Result<Long> createElder(@RequestBody @Valid ElderCreateDTO dto) { // 身份证号查重 Long existId = elderMapper.findIdByIdCard(dto.getIdCard()); if (existId != null) { return Result.error("该身份证号已存在档案，请勿重复建档"); } ElderInfo elder = new ElderInfo(); BeanUtils.copyProperties(dto, elder); elder.setStatus(1); elderMapper.insert(elder); return Result.success(elder.getId()); }

创建档案后，接下来是健康指标的录入。健康指标录入的入口分两类：一类是服务站工作人员手动录入，另一类是体检机构批量导入。手动录入时前端按指标类型动态渲染表单，比如选择了“血压”就展示收缩压、舒张压两个输入框，并带上正常范围校验：收缩压90-139mmHg，舒张压60-89mmHg。超出范围时前端先警告，但允许保存——因为异常数据本身就是健康风险信号，不能因为校验就拒之门外。真正起作用的是后端的预警服务：保存时检查指标是否超出预设阈值，超出便生成一条待处理的预警记录，推送至社区医生的管理端。

3.2 预约、派单、反馈的订单链路实现

订单模块是系统里逻辑最重的部分，状态机贯穿始终。我们在ServiceOrderService里做了一个transition方法，所有状态变更必须走这个方法，不允许在Controller里直接修改状态字段：

public boolean transition(Long orderId, int fromState, int toState) { ServiceOrder order = getById(orderId); if (order.getState() != fromState) { throw new BusinessException("非法状态流转，当前状态为：" + order.getState()); } if (!STATE_TRANSITION_MAP.get(fromState).contains(toState)) { throw new BusinessException("不支持从" + fromState + "跳转到" + toState); } LambdaUpdateWrapper<ServiceOrder> wrapper = new LambdaUpdateWrapper<>(); wrapper.eq(ServiceOrder::getId, orderId) .eq(ServiceOrder::getState, fromState) // 条件更新，保证原子性 .set(ServiceOrder::getState, toState); return update(wrapper); }

这个设计看起来简单，实际上避免了后面会讲到的“状态跳变脏数据”问题。

预约接口的时序逻辑是：前端提交预约信息 → 后端校验时间冲突 → 创建订单并置为待审核 → 调度员审核通过后进入待派单 → 派单规则自动匹配可用服务人员 → 服务人员接单。自动派单的逻辑一开始设想得很复杂，想引入评分、距离、历史好评率加权，后来实测发现社区场景下最关键的约束只有一个：服务人员在该时段是否已有其他订单。于是派单规则简化为两步：先按服务项目所需的技能标签筛选人员，再排除当前时段冲突的人员，最后按“最近空闲优先”排序，取第一位。规则简化之后，可解释性大幅提升，调度员在界面上能看到每条派单记录的打分依据，也就愿意信任推荐结果。

服务执行完成后的反馈环节，实现了一个轻量化的“电子确认”机制：服务人员在App端提交完成申请，老人或家属在服务站Web端或小程序端确认，确认后订单进入已完成。如果超过24小时未确认，系统自动将状态置为已完成但标记为“待回访”。这样做既避免了服务人员单方面锁单，又不让订单在终态卡太久。

3.3 消息通知与健康预警的触发机制

消息通知模块采用了“数据库轮询 + 定时任务”的方式，没有引入消息队列。社区站点规模不大，峰值消息量一天几百条级别，引入MQ反而让运维变复杂。我们用Spring的@Scheduled注解实现了一个每分钟跑一次的扫描任务：

@Scheduled(cron = "0 * * * * ?") public void scanUnsentNotifications() { List<Notification> list = notificationMapper.selectList( new LambdaQueryWrapper<Notification>() .eq(Notification::getStatus, 0) .le(Notification::getNextSendTime, LocalDateTime.now()) ); for (Notification n : list) { sendByChannel(n); // 按渠道发送：站内信/短信/微信模拟 n.setStatus(1); notificationMapper.updateById(n); } }

健康预警则是独立于消息通知的一层。当健康指标异常被写入后，会关联生成一条预警记录并插入通知表。针对长期未服务预警，我们每天凌晨执行一个统计任务，找出“最近30天没有任何服务记录且档案标记为独居”的老人，生成提醒通知给服务站。上线测试阶段我们发现这个规则误报率偏高，原因是很多老人只是回子女家暂住并未办手续，后来加了一个“暂停服务”字段，老人在系统内的状态变为暂停后就不再纳入预警统计。这种边界情况如果不做需求验证，上线后被投诉几次就得连夜加补丁。

4. 两个让我熬夜到凌晨的排错过程

4.1 并发预约“撞单”的定位与修复

在联调阶段测试人员反馈了一个严重问题：两名测试账号同时为同一位老人预约同一时段的上门保洁，系统竟然生成了两条订单，而且审核都通过了。第一反应是检查代码逻辑，结果发现派单时确实查询了这个时段是否已有订单，看起来没有问题。问题出在哪？

拉出日志仔细对时间线，才发现是并发“穿透”：两个请求在同一毫秒级内都执行了“查询该时段无冲突”的判断，然后都通过了校验，先后插入各自订单。这个场景在单用户手工测试时永远不会出现，但实际服务站高峰期完全可能同时接到两个家属的电话预约。修复方案我们采用了最稳妥的两层防线：

第一层，数据库层唯一约束。在service_order表针对(service_person_id, service_date, start_time, end_time)创建一个唯一索引。只要两个订单派给了同一个人、同一时段，数据库直接拒绝第二条插入。这个约束是兜底，代码再有Bug它也拦得住。

第二层，Redis分布式锁，在生成订单前按“老人ID+服务时间”维度加锁，锁内完成冲突查询与插入：

String lockKey = "order:lock:" + elderId + ":" + serviceDate + ":" + startTime; boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS); if (!locked) { throw new BusinessException("当前时段已有预约在处理中，请勿重复提交"); } try { // 查询冲突、创建订单 } finally { redisTemplate.delete(lockKey); }

唯一索引防止了数据的物理重复，Redis锁避免了大量无效查询打到数据库。这样双保险上线后，再没有出现过撞单的情况。这件事给我最大的启发是：凡是涉及“先查后写”的逻辑，都要默认它会被并发执行，不是只有高并发架构才需要关心这些问题。

4.2 服务单状态“跳变”引发的脏数据排查

另一个棘手问题出现在服务单状态这里。现场人员反馈，部分订单从“待执行”直接变成了“已完成”，没有经过“执行中”。一开始怀疑是前端按钮的问题，仔细排查后发现原因是：移动端网络不稳定，服务人员在点击“开始服务”时请求超时，然后他重试点击“完成服务”，而后端的两个请求因为网络乱序，到达服务器时顺序反转，导致“完成”接口先执行了。

当时的状态更新代码没有任何前置状态校验，只是机械地把状态改成目标值。修复思路就是前面提到的状态机方案：所有状态流转必须校验当前状态，并且用条件更新（WHERE state = ?）保证原子性。非法的流转链直接被拒绝并返回明确错误提示。

这次排错之后，我们把全部状态变更都收敛到了状态机服务里，前端不再展示裸的状态修改按钮，而是按动作触发接口（如“开始服务”“完成服务”），由后端判断当前状态是否允许执行该动作。用一张表来记录状态流转规则：

这个表格最终也被做成了配置化数据，存到数据库配置表里，后续调整流程不需要重新发版。从这个Bug开始，我养成了一个习惯：任何状态字段的更新，前端传的是动作，不是状态值。

5. 测试、部署与调优复盘：上线不是终点

5.1 接口测试与并发模拟的实操方法

项目测试分了三层推进。

第一层是功能测试。每个业务模块按角色编写测试用例，重点覆盖权限边界，比如服务人员账号不能查询其他老人的档案信息、家属账号只能查看自家老人的服务记录。这类问题靠人工点一遍不一定能发现，因为很多异常情况需要构造特殊数据。

第二层是单元测试。对状态机、派单规则、健康指标判定这类纯逻辑部分用JUnit写断言测试，保证后续迭代不会改坏旧功能。比如状态机测试用例，就把上表所有合法流转和非法流转各写一遍，全绿才算通过。

第三层是并发测试。用JMeter模拟100个线程同时为不同老人预约同一时段同一服务人员的场景，断言最终成功创建的订单数不超过该服务人员时段的承载量。实测中我们发现了两个问题：一是数据库连接池默认大小偏小，高并发下出现连接等待；二是部分慢查询没有走到索引。针对这两个问题，把连接池从默认10调到50，给高频查询做了索引优化，并发表现明显好转。

5.2 部署方式与运行参数调整经验

部署选型上，我们最终选择Docker Compose方式。整套服务包括后端应用、MySQL、Redis、Nginx（静态前端资源），三个容器一条命令起停。这样做的好处是交付时不再需要写一长串环境搭建文档，新服务器上只要装了Docker就能快速复制一套一样的运行环境。

JVM参数这块也有讲究。刚开始直接默认参数跑，结果一周后出现内存持续增长，排查发现是默认的堆内存上限跟宿主机不匹配。后来显式配置了：

-Xms512m -Xmx512m -XX:+UseG1GC

业务量不大，512M足够。另外给Spring Boot加了spring.datasource.hikari.maximum-pool-size=50、minimum-idle=10，以及Redis客户端的连接池参数。这些参数虽然不是什么高深技术，但在运行过程中确确实实避免了“服务没挂但接口卡死”的尴尬状态。

上线后的监控我们用了最朴素但有效的方式：每天定时跑一份日志摘要，统计异常订单数、预警触发数、未处理预约数，同时保留一份当日全部异常日志的独立文件。配合定时任务看板，运营人员每天打开看一眼就能知道系统健康度。

部署阶段还有个值得记录的小细节：第一次上线时Nginx没配WebSocket相关参数，结果前端页面正常、消息实时刷新功能失效。排查半天才发现是Nginx代理的长连接超时时间太短。加上proxy_read_timeout 3600s和相关头部配置后，消息推送恢复正常。这个坑几乎每个做前后端分离部署的人都会遇到，提前提个醒。

最后再分享一点我自己的体会

系统上线运行一个季度后复盘，我发现最关键的其实不是技术选型多先进、架构多复杂，而是每一个功能设计是否贴合服务站的真实工作节奏。最初我们设计了一个很强的数据统计大屏，结果调度员根本不用，他们最常用的是“今天的预约列表”和“哪个服务人员有空”。后来我们把首页改成这两个信息高亮展示，使用率立刻上去了。做这种业务系统，前期多花时间在现场观察用户怎么干活，比多写几千行代码有价值得多。

如果你也在做类似的Spring Boot实战项目，建议把排错过程完整记录下来，这些才是项目里最值钱的经验。后续如果条件允许，可以给系统加一个老人家属端的小程序，再对接一些简单的IoT体征设备，比如血压计数据自动上传。业务系统的演进方向，永远跟着真实需求走。