1. 项目背景与需求分析

养老院管理系统在人口老龄化加剧的背景下显得尤为重要。随着我国60岁以上人口占比突破18%，传统养老院手工登记、电话预约的方式已经无法满足实际需求。这个基于SpringBoot的养老院预约系统正是为解决以下痛点而生：

1. 信息不对称：家属无法实时了解养老院床位、服务、价格等情况
2. 预约效率低：传统方式需要多次往返养老院提交材料
3. 管理混乱：护工排班、老人健康档案等纸质记录易丢失
4. 服务断层：紧急呼叫、用药提醒等关键服务缺乏系统支持

我在实际调研中发现，即使是中高端养老机构，仍有超过60%在使用Excel表格管理入住信息。这种状况直接导致了三个典型问题：

• 床位空置与排队等候同时存在（信息不透明）
• 护工与老人配比不合理（缺乏智能排班）
• 突发情况响应迟缓（无预警机制）

2. 系统架构设计

2.1 技术选型决策

选择SpringBoot作为后端框架基于三个关键考量：

1. 快速迭代：养老政策经常调整，需要系统能快速响应变更
2. 微服务友好：未来可能对接医保、卫健等政府系统
3. 生态丰富：SpringCloud Alibaba可无缝集成短信、支付等功能

技术栈对比表：

2.2 核心模块划分

系统采用分层架构设计：

养老院管理系统 ├── 用户端（小程序） │ ├── 家属模块：预约、缴费、视频探视 │ └── 老人模块：服务呼叫、用药提醒 ├── 管理端（PC） │ ├── 运营模块：床位管理、费用统计 │ └── 医护模块：健康档案、排班管理 └── 公共服务 ├── 消息推送（微信模板消息） └── 支付对接（微信支付/医保）

数据库设计关键点：

• 采用软删除设计（is_deleted字段）
• 老人健康数据使用MySQL JSON类型存储
• 预约记录与床位关联使用乐观锁控制并发

3. 关键功能实现细节

3.1 微信小程序端开发

导航栏适配方案：

// app.js中动态计算导航栏高度 wx.getSystemInfo({ success: (res) => { const menu = wx.getMenuButtonBoundingClientRect() this.globalData.navBarHeight = (menu.top - res.statusBarHeight) * 2 + menu.height } })

文件上传避坑指南：

1. 服务端需配置MPConfig拦截器处理微信格式
2. 文件大小限制在10MB以内（养老院常需上传体检报告）
3. 使用OSS临时签名上传避免服务端带宽压力

实际开发中发现iOS真机访问视频URL会报MEDIA_ERR_NETWORK错误，解决方案是在Nginx配置中添加：add_header 'Access-Control-Allow-Origin' '*' always;

3.2 预约业务流实现

核心预约逻辑时序：

1. 家属提交基本信息（含老人身份证）
2. 系统自动校验医保资格（对接政府接口）
3. 展示可选床位（按护理等级过滤）
4. 线上签订电子协议（使用腾讯电子签SDK）
5. 支付定金（对接微信支付分账系统）

并发控制方案对比：

// 乐观锁实现（适合养老院场景） @Transactional public boolean reserveBed(Long bedId, Long version) { int updated = bedMapper.updateBedStatus( bedId, BedStatus.RESERVED, version); return updated > 0; }

3.3 健康监测预警系统

采用规则引擎实现多级预警：

• 一级预警（短信通知）：血压连续3次超标
• 二级预警（微信提醒）：用药时间错过30分钟
• 三级预警（电话呼叫）：跌倒检测触发

体温数据聚合查询示例：

-- 按小时统计体温异常次数 SELECT DATE_FORMAT(record_time, '%Y-%m-%d %H:00') AS hour, COUNT(*) AS abnormal_count FROM health_data WHERE temperature > 37.3 GROUP BY hour

4. 部署与运维实践

4.1 多环境配置方案

使用SpringBoot Profile实现：

# application-dev.yml wxpay: mch-id: 开发商户号 notify-url: https://dev.example.com/callback # application-prod.yml wxpay: mch-id: 生产商户号 notify-url: https://api.yourdomain.com/callback

4.2 性能优化实战

1. 缓存策略：

   • 床位信息：Redis缓存5分钟
   • 价格表：本地Caffeine缓存
   • 健康数据：不缓存（实时性要求高）

2. SQL优化案例：

// 错误写法（N+1查询问题） List<Bed> beds = bedMapper.selectAll(); beds.forEach(bed -> { bed.setReservations(reservationMapper.selectByBedId(bed.getId())); }); // 正确写法（联合查询） @Select("SELECT b.*, r.* FROM bed b LEFT JOIN reservation r ON b.id = r.bed_id") List<BedDTO> selectBedsWithReservations();

4.3 监控体系建设

1. SpringBoot Admin监控项：

   • 数据库连接池使用率
   • 微信API调用成功率
   • 定时任务执行耗时

2. 自定义健康检查端点：

@Endpoint(id = "payment") public class PaymentHealthEndpoint { @ReadOperation public Health check() { boolean isHealthy = wxPayService.checkConnection(); return isHealthy ? Health.up().build() : Health.down().build(); } }

5. 典型问题解决方案

5.1 微信登录态维护

采用双Token机制：

1. 短期Token（2小时）：用于常规API调用
2. 长期Token（30天）：仅用于刷新短期Token

刷新流程时序：

小程序 → 检测Token过期 → 携带refreshToken调用刷新接口 → 服务端校验 → 返回新Token → 小程序更新本地存储

5.2 并发预约冲突处理

实际项目中遇到的典型案例： 某热门养老院推出50个特惠床位，瞬间收到300个请求。最初方案导致超卖20个床位，最终采用Redis分布式锁+数据库乐观锁双重保障：

public boolean concurrentReserve(Long bedId, Long userId) { String lockKey = "bed_lock:" + bedId; try { // 尝试获取分布式锁（3秒超时） boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", 3, TimeUnit.SECONDS); if (locked) { return bedService.reserveWithOptimisticLock(bedId, userId); } return false; } finally { redisTemplate.delete(lockKey); } }

5.3 隐私数据保护

针对小程序收集老人信息的合规方案：

1. 敏感字段加密存储（如身份证号使用AES加密）
2. 数据库审计日志记录所有查询操作
3. 实现《隐私政策》动态确认功能：

public void saveUserConsent(Long userId, String policyVersion) { if (!latestPolicyVersion.equals(policyVersion)) { throw new BusinessException("请同意最新版隐私政策"); } // 记录用户同意记录 }

6. 项目演进方向

1. 智能推荐扩展：

   • 基于老人健康数据推荐合适床位（如离护士站距离）
   • 根据护理记录预测资源需求（机器学习模型）

2. IoT设备集成：

   # 伪代码：跌倒检测设备数据接入 def handle_fall_detection(sensor_data): if sensor_data['impact'] > threshold: send_alert_to_nurse_station( location=sensor_data['room'], urgency='high' )

3. 家属端功能增强：

   • 视频探视预约系统
   • 电子围栏异常出入预警

这个项目在落地实施过程中，最大的收获是要重视"银发群体"的特殊交互需求。例如我们发现：

• 字体大小需要比常规系统大20%
• 重要操作需要语音引导
• 颜色对比度要符合WCAG AA标准 这些细节往往在技术文档中不会提及，但却直接影响系统的实际使用效果。