企业官网建设流程全解析

简介：基于Java平台的老年人健康管理应用设计源码，是一套面向高校实训、课程设计与初级Java开发者的完整项目，针对老年用户提供健康数据录入、分析与个性化建议等功能，帮助读者掌握Controller、Service、Mapper、Bean分层架构与业务实现。压缩包共36个文件，包含30个Java源文件、3个XML配置、1个Git忽略文件、1个工程模块描述文件及1个说明文档，整体约120KB；Java文件覆盖界面控制、数据处理与业务逻辑，XML配置负责运行环境与数据库连接等参数。目前已有260人学习下载。这套源码的核心价值在于接口与类划分清晰，适合直接导入开发工具运行调试，可参考用户登录、健康指标管理、用药提醒、检查记录与医生关联等模块的代码组织方式，并基于医学知识库扩展告警逻辑，对理解业务系统分层、项目文件组织及老年健康场景落地均有实际帮助。

1. 为什么说老人健康管理系统的难点不在 Java 代码里

老人在家里测完血压，数值记在小本子上，子女周末回来才发现这周有三天高压超过 170，但老人自己觉得“没啥感觉”。这类场景催生了很多健康管理应用，而市售的养老 SaaS 大多按人头收年费，一个社区养老服务站几套系统下来，费用够自己养一台服务器加一个兼职开发了。基于 Java 平台的老年人健康管理应用设计源码，是这类需求里最常被拿来做二次开发的一条路线。它的核心壁垒不在 Spring 写得多花哨，而在数据模型能不能兼容各类血压计和手环、提醒会不会被老人当作骚扰、误报会不会把家属吓出毛病。这篇不打算做科普，直接按源码工程的拆法，从选型聊到表结构，再落到定时任务与推送边界，最后把那几条我改到凌晨的坑一并写出来。

2. 技术选型与工程骨架：先选对 JDK，再谈 Spring Boot 版本

2.1 为什么 Java 生态在这条赛道仍然是最稳的选择

老年人健康管理应用有一个特点：硬件对接几乎绕不开。血压计、血氧仪、智能手环、智能药盒，这些设备的 SDK 大多只提供 C/C++、Java 或者串口指令三种接口。Java 的串口通信库（比如市面上常见的开源的 serial 实现）和蓝牙通信方案经过多年沉淀，踩坑资料最全。相比 Node.js 和 Python，Java 在对接串口设备时有一个巨大的优势：JDK 自带的体系对“设备断连后重连”“数据粘包半包”这类问题的处理模式，在社区里已经形成了大量可复用的写法，招聘一个 Java 后端工程师也比招一个熟悉硬件通信的 Node 工程师容易得多。

再看部署环境。社区养老站点的服务器通常是几年前的配置甚至一台迷你主机，内存可能只有 4G。Spring Boot 2.7.x 在 2G 内存下能跑得比较稳，而 Spring Boot 3.x 虽然性能更好，但强制 JDK 17 带来两个实际问题：某些血压计厂商的 SDK 仍然是 JDK 8 编译的，放进 JDK 17 运行时会出现模块访问报错；另一个是运维同学对 JDK 8 的 GC 参数和排查命令更熟悉。所以我的建议是：这个方向做产品选型，优先 JDK 8 + Spring Boot 2.7.x，这条路最稳。

选型表里没有引入消息队列和微服务，这是刻意为之。一个社区站点的老人数量通常在一千以内，单机 Spring Boot 完全能扛住。早期把架构做得太重，后续每次发布都要处理多个服务的一致性，对一个小团队来说是负担而不是效率。

2.2 用 Maven 搭出能直接二次开发的工程骨架

拿到一份源码，先别急着看业务代码。我一般会先看pom.xml的依赖和目录结构，判断这个工程是不是真正能跑的东西。伪源码项目最常见的特征就是只有几个 Controller 类和一个空的 Service 接口，或者没有任何数据库脚本。下面是这类工程常见的依赖组织方式：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <properties> <java.version>1.8</java.version> <mybatis-plus.version>3.5.4</mybatis-plus.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>${mybatis-plus.version}</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

依赖里特别注意两点。第一，starter-web和mybatis-plus-boot-starter是底线，缺了这两个，整个项目连 HTTP 接口都起不来。第二，mysql-connector-java的 scope 是 runtime，编译期不需要它，但运行期必须有，如果你拉到的源码里这个依赖缺失，启动时会在数据源初始化阶段直接抛 ClassNotFoundException。MyBatis-Plus 版本建议锁 3.5.x，不要追最新，因为 3.5.4 之后的部分版本在分页插件上调整过拦截器注册方式，和 Spring Boot 2.7 的自动配置有兼容差异。

工程目录建议按下面这个结构拆，每个模块职责清晰，二次开发时容易定位：

health-manage/ ├── health-common/ # 通用工具、常量、统一返回体 ├── health-domain/ # 实体类、DTO、枚举 ├── health-dao/ # Mapper 接口与 XML，放分页插件配置 ├── health-service/ # 业务服务、定时任务、通知网关 ├── health-controller/ # REST 接口，只做参数接收与校验 └── health-admin/ # 启动模块，放 Application 类和配置文件

实际执行时，我见过很多团队把实体类和 Controller 全塞进一个包，老人数量到两三百之后，改一个字段能引发多个文件的循环依赖。按上面的分包拆开，维护成本会明显下降。启动模块单独放在health-admin里，还能顺手把定时任务的开关放在配置文件中控制，避免测试环境每次启动都自动发短信。

2.3 配置文件的坑：多环境 profile 与硬件 SDK 的 JDK 版本冲突

用 Spring Boot 写配置时，一份application.yml加三份 profile 是最基本的操作，但源码工程里常见的问题是application-prod.yml里的数据库密码或短信密钥被明文提交，或者根本没有application-test.yml。我通常的做法是：

spring: profiles: active: dev --- spring: config: activate: on-profile: dev datasource: url: jdbc:mysql://localhost:3306/health_manage?serverTimezone=Asia/Shanghai&useSSL=false&characterEncoding=utf8 username: root password: root redis: host: localhost port: 6379

dev 环境用本地库，test 环境连测试库，prod 环境的密码通过环境变量注入，不写死在文件里。社区项目通常没有专门的运维人员，所以我会在工程根目录放一个README文件，把环境变量DB_PASSWORD、SMS_SECRET_KEY的配置命令写在里面，接手的同事复制命令就能跑通。

硬件 SDK 兼容问题在配置阶段就要确认。某血压计厂商的官方 SDK 是用 JDK 8 编译的，里面用到了sun.misc.Unsafe的某些内部方法，JDK 11 之后这些方法默认被模块系统限制，运行期才能看到错误。等到项目启动后再发现，排查链条会很长。我一般是在拉取源码后的第一天，就把所有硬件 demo 跑一遍，确认 JDK 版本没问题再做业务改造。

注意：如果源码的 pom 里<java.version>是 1.8，但启动类所在的模块依赖了 Spring Boot 3.x，这类混用版本的项目直接放弃为准，跑通它的成本比你自己重建一个还高。

3. 健康档案与测量数据：五张表的结构与一条血压数据的写入链路

3.1 为什么要用“主记录 + 指标明细”而不是老式的一行多列

健康监测数据有个特点：血压计会同时给出高压、低压、心率三条数据，血氧仪给出血氧饱和度和脉率，智能手环还能给出体温和步数。如果按照老式做法，在一张表里建systolic、diastolic、heart_rate、spo2、temperature这些字段，第一次上线没问题，第二个月要接入一款测血糖的新设备时，你就要去改表结构、改实体类、改 Mapper。更麻烦的是，老设备的测量记录里没有血糖值，查询历史趋势时那一列全是 NULL，写图表接口时还要做大量空值判断。

我的建议是拆成health_record和health_metric两张表。health_record只保存一次测量的主信息，比如哪个老人、哪台设备、什么时间测的；health_metric保存指标项，每一条记录是“高压：170”这样的键值对。这样新增设备时不用改表，只需在枚举里加一个指标类型。启动时读取设备配置文件，决定给哪些指标配置告警上下限，这属于可配置的业务设计。

这个方案也有代价：查询一次完整测量的数据要从两张表取数，比单表多一次 join。但老人测量频率一天最多两三次，数据量很小，加一个索引后性能完全不是问题。如果你硬要用一行多列的表，指标一旦超过 20 个，表就会变得极难维护，而且很多列根本不会用上。健康数据的表结构是为了“接得住未来新设备”，不是为了省这次 join。

3.2 建表 SQL：从老人档案到指标明细一次建完

源码工程里最值钱的资产其实是可执行的建表脚本。拿到源码后，我通常会先执行一遍全部 DDL，发现字段缺注释、没有索引、字符集不是 utf8mb4 的，都会记进改造清单。下面这组 DDL 覆盖了老年人健康管理最核心的五张表，字段设计经过实际项目打磨：

CREATE TABLE elder_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, family_id BIGINT NOT NULL COMMENT '家庭ID，关联家属账号维度', name VARCHAR(64) NOT NULL COMMENT '老人姓名', id_card VARCHAR(32) NULL COMMENT '身份证号，选填', birth_date DATE NULL COMMENT '出生日期，用于年龄换算', mobile VARCHAR(16) NULL COMMENT '老人本人手机号，可能没有', blood_type VARCHAR(8) NULL COMMENT '血型，急救场景需要', address VARCHAR(255) NULL COMMENT '住址，用于上门急救导航', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_family (family_id), KEY idx_mobile (mobile) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='老人档案表'; CREATE TABLE health_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, elder_id BIGINT NOT NULL COMMENT '老人ID', device_no VARCHAR(64) NULL COMMENT '设备编号，同一老人可能有多个设备', measured_at DATETIME NOT NULL COMMENT '实际测量时间', source TINYINT NOT NULL DEFAULT 1 COMMENT '1手动录入 2一体机 3手环', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_elder_time (elder_id, measured_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='健康测量主记录表'; CREATE TABLE health_metric ( id BIGINT AUTO_INCREMENT PRIMARY KEY, record_id BIGINT NOT NULL COMMENT '关联健康记录ID', metric_type VARCHAR(32) NOT NULL COMMENT 'systolic/diastolic/heart_rate/spo2等', metric_value DECIMAL(10,2) NOT NULL COMMENT '测量值，统一用十进制', unit VARCHAR(16) NOT NULL COMMENT '单位，mmHg/mmHg/bpm/%', alarm_level TINYINT NOT NULL DEFAULT 0 COMMENT '0正常 1偏高 2危险', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_record (record_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='健康指标明细表';

这里有三处容易被忽略的设计。第一，elder_info里的family_id不是外键字段，它只是逻辑维度，用于之后按家庭查询所有老人的健康汇总；真正建模时我不建议在业务表里建物理外键，老人档案删除或合并时外键会带来巨大麻烦。第二，health_record.measured_at和health_metric.alarm_level这两个字段是核心业务字段，前者决定了之后趋势图时间轴的准确性，后者是预警系统的判断依据。第三，DECIMAL(10,2) 不能改成 FLOAT，血压高值 170.5 用浮点存储时容易出现 170.49999 这样的偏差，推送告警内容时会出现一个让家属困惑的数值。

3.3 写入链路：一次血压测量如何落到库里

硬件设备上传数据和服务端手动录入是两种常见写入方式。手动录入的典型场景是老人不会用智能设备，由工作人员读数后录入工作站；设备上传则是一体机通过 HTTP 接口把 JSON 推到后端。两者在写入事务上是同一条链路，Command 对象里都包含一组指标列表。我把接收端设计成“一次测量主记录 + N 条指标明细”的原子操作，要么全部成功，要么全部回滚：

@Service @RequiredArgsConstructor public class HealthRecordService { private final HealthRecordMapper recordMapper; private final HealthMetricMapper metricMapper; @Transactional(rollbackFor = Exception.class) public Long addRecord(AddHealthRecordCommand cmd) { HealthRecord record = new HealthRecord(); record.setElderId(cmd.getElderId()); record.setDeviceNo(cmd.getDeviceNo()); record.setMeasuredAt(cmd.getMeasuredAt()); record.setSource(cmd.getSource()); recordMapper.insert(record); List<HealthMetric> metrics = cmd.getMetrics().stream() .map(m -> { HealthMetric metric = new HealthMetric(); metric.setRecordId(record.getId()); metric.setMetricType(m.getType()); metric.setMetricValue(m.getValue()); metric.setUnit(m.getUnit()); metric.setAlarmLevel(HealthLevelEvaluator.evaluate(m.getType(), m.getValue())); return metric; }) .collect(Collectors.toList()); metricMapper.batchInsert(metrics); return record.getId(); } }

这段写入逻辑的核心是@Transactional(rollbackFor = Exception.class)。默认的事务回滚只处理 RuntimeException，如果业务代码里把写入数据库的异常包装成了自定义的 CheckedException，不加这个属性事务就不会回滚，结果会出现主记录已经写入、明细却缺失的脏数据。另一个重点是先 insert 主记录拿到自增 id，再往明细里填recordId，批量插入时如果明细条数多，MyBatis-Plus 的batchInsert底层会走一条 SQL 多个 VALUES，而不是逐条插入，这一点对写入性能非常关键。

3.4 Mapper 层与指标值的分级评估

HealthLevelEvaluator.evaluate是一个纯静态方法，根据指标类型和数值返回 0/1/2 三个级别。要小心的是，不同设备的量纲可能不一致。比如某款血氧仪返回的是 98（百分比），而另一款返回的是 0.98，如果不在写入链路统一转成百分比，告警模块就会把 0.98 当作异常低值疯狂报警。我一般在枚举里就约定了标准单位，设备适配层负责换算，业务层只认统一量纲。

Mapper 层用 MyBatis-Plus 时，单表 CRUD 可以完全不用写 XML，但这部分有个隐藏问题：health_metric表的批量插入，如果在application.yml中没有开启rewriteBatchedStatements=true，MySQL 的 JDBC 驱动默认会逐条执行，性能会慢一个数量级。常见做法是在数据库连接 URL 上加rewriteBatchedStatements=true。源码里如果没配这个参数，当一台一体机一次上传 30 个老人的晨检数据时，接口响应时间会明显变慢，看到这种症状我第一反应就是去查连接参数。

设置好参数后，这个写入接口还应该增加幂等控制。一体机偶尔会断网重传，服务端收到两条完全一样的数据，如果没有去重，老人一天会收到两条重复的测量记录。此处我使用device_no + measured_at + elder_id建一个唯一索引作为最后防线，写入冲突时捕获 DuplicateKeyException 返回记录已存在。

4. 用药提醒与异常预警：让通知不打扰人又被家属信任

4.1 别用固定时刻的定时任务，为什么选分钟级扫描

老年人健康管理的两个核心回访指标，一个是药品按时服用率，一个是异常指标的及时知晓率。药品提醒如果做得太粗暴——每天早上 8 点整扫一次数据库，出问题的地方在于：部分老人在配置用药计划时把时间设成 7:50 或 8:10，有的老人中午的药设定 12:30，整点扫描需要为每个时刻都建一条 cron 表达式，配置量指数级增长，而且漏配一个时间点这个老人的提醒就静默了。

常见的替代方案是分钟级扫描。定时任务每 5 分钟执行一次，查询当前时间到未来 5 分钟窗口内所有到期的提醒计划，命中窗口就触发。这样做的好处是，无论老人把时间设成几点几分，都能被覆盖到，不需要维护上百条 cron。5 分钟窗口对药物提醒来说完全够用，药盒上的指示灯会在整点亮起，短信提前 2 分钟到达也不会造成困惑。窗口太大会造成“提前 4 分钟收到提醒”的错乱感。

注意：窗口不能设置为 1 分钟，因为数据库查询和发送短信的耗时、以及定时任务本身的调度延迟，会让部分提醒直接错过窗口。5 分钟是稳定性和及时性之间的平衡点。

4.2 用药计划的表设计与提醒去重

用药计划要支持“按天重复”和“特定时间段使用”两种模式。比如降压药每天早上一次，这个计划连续执行 30 天；抗生素按疗程吃 7 天，到第 8 天就不能再提醒。对应的表设计里必须有start_date、end_date和time_slots三个关键字段，time_slots存储一个 JSON 数组，例如["07:30","19:30"]，表示一天两次。定时任务每 5 分钟扫描时，按当前日期过滤掉未开始或已结束的计划，再用当前时间匹配time_slots里的小时和分钟。

提醒去重是必须考虑的问题。同一个计划在同一个日期的同一个时间点，只能发一次提醒。如果服务重启或短信通道超时重试，可能把同一条提醒发两次。我的方案是用 Redis 的setIfAbsent做原子去重：

@Component @RequiredArgsConstructor public class MedicationReminderTask { private final RemindPlanMapper planMapper; private final RemindLogMapper logMapper; private final StringRedisTemplate redisTemplate; private final NotifyGateway notifyGateway; @Scheduled(cron = "0 0/5 * * * ?") public void scanDueReminds() { LocalDateTime now = LocalDateTime.now(); LocalDateTime windowEnd = now.plusMinutes(5); List<RemindPlan> plans = planMapper.selectDuePlans(now, windowEnd); for (RemindPlan plan : plans) { String key = "remind:plan:" + plan.getId() + ":date:" + LocalDate.now() + ":slot:" + plan.getSlotTime(); Boolean first = redisTemplate.opsForValue() .setIfAbsent(key, "1", Duration.ofHours(24)); if (Boolean.TRUE.equals(first)) { NotifyResult result = notifyGateway.send(plan); insertRemindLog(plan, result); } } } }

这段代码有两个关键点。第一，setIfAbsent是原子操作，多个实例同时执行时只有一个线程能拿到true，单机部署时可以不加分布式锁，多实例部署时也能兜住。第二，key 里面包含了planId + 日期 + 时间槽，这样同一天不同时间段的提醒互不影响，同一个时间槽次日会重新开始计算。Duration.ofHours(24)让 key 在当天内都有效，即使定时任务因为故障在下午才恢复执行，也不会把早晨已经提醒过的消息再发一遍。

insertRemindLog写入本地数据库，作为发送记录留存。短信通道如果返回失败，通知网关内部会有一次重试，重试次数超过阈值后写入失败日志，值班人员可以定期捞取。

4.3 预警分级：夜间静默、晨峰补推、连续三次才打扰

异常预警比用药提醒更容易引发投诉，核心矛盾是“漏报的后果很严重，误报又会被家属拉黑”。某位老人在凌晨 3 点血压测得 160/95，这个数值按一般标准算偏高，但睡眠状态下人体血压本来就会下降，一次突发的高值可能是睡姿压迫了袖带，也可能是设备测量误差。如果这个级别也立即给家属发短信，两周之后家属就会对通知麻木，真正危险时反而被忽略。

我采用的分级逻辑是：夜间 22:00 到次日 7:00，只有达到危险级别的数值才推送，偏高级别只入库不推送，次日早晨统一补推。白天时段，单次偏高不推，只有同一指标连续三次测量超过阈值才推给家属。这样做有一个好处：把“测量误差”和“真实趋势”区分开。血压计袖带缠绕不当的误差通常是一次性的，连续三次都超标的可能性很低；而高血压患者的数值上升是一个渐进过程，连续三次检出后才能确认趋势。

晨峰补推的时机放在上午 9 点，这一时刻家属通常已经起床，短信阅读率高。补推的内容格式为“某老人昨夜 23:30 血压 165/95，已达偏高等级，今晨 7:00 复测 155/90，请关注”。这样家属看到的是完整的趋势变化，而不是一个孤立数字。预警模块的代码可以从配置表里读阈值，我在源码里设的是“收缩压 > 180 或舒张压 > 110 为危险”，这个值来自常见的高血压分级标准，但不同老人的基础血压差异很大，体弱老人 150 就可能头晕，所以更稳妥的做法是给每位老人的档案里加一项个性化阈值。

4.4 通知通道的降级：短信发不出去怎么办

短信通道运营商会因为签名审核、余额不足、内容含违规词等原因返回失败。推送失败后如果没有任何补偿机制，提醒就算漏了。我的做法是在通知网关里做一个三级降级：第一级走短信，第二级走语音电话回调，第三级是 APP 的站内通知。老人手机上如果没有安装配套应用，语音电话就是最后一根救命稻草。语音电话的费用是短信的三到五倍，所以我只对“危险级别”和“连续三次偏高”这两种场景启用语音降级。

定时任务的执行时长也要监控，每 5 分钟跑一次，如果上一次任务还没跑完，Spring Task 默认会排队等下一次执行，时间一长会堆积任务。代码里可以在任务开始和结束时记录耗时，超过 30 秒就输出一条 WARN 日志。数据量大时更建议引入@Scheduled搭配一个线程池配置，只用一个线程跑任务，避免并发扫描把数据库连接池占满。

5. 避坑指南：从提醒丢失到凌晨误报的五个典型翻车现场

5.1 老人说没收到提醒，后台却显示已发送

现象：家属反映老人当天没有按时吃药，后台remind_log表里却明明记录着“发送成功”。

原因：短信发送成功只代表运营商接受了这条消息，不代表手机收到了。老人手机大多是国产安卓机，系统自带省电策略会在后台杀死推送服务的进程，自定义 APP 的消息通道经常被系统拦截，很多手机默认禁止应用自启动。

解决：把关键提醒的推送通道从 APP 推送改成短信。吃药提醒类消息的到达优先级高于成本考量，短信是运营商级别的通道，系统杀不掉。如果短信成本承受不了，至少要对“危险异常”和“连续三次偏高”这类消息保证短信送达。另外提醒包里要附带下一次提醒的时间内容，例如“下次服药时间为 19:30”，老人即使这次没看到，也能从短信记录里找到上下文。

5.2 血压计串口偶发读取失败

现象：一体机每运行一两天就会出现一次“设备无响应”，重启程序后恢复，过一天又复现。

原因：串口被多个线程同时操作，或者上一次读取超时后端口没有正常释放。部分血压计 SD 的读取代码没有做并发保护，两个线程同时打开同一端口，设备直接死锁。

解决：对串口操作做单例锁，同一台设备同一时刻只允许一个线程持有读取权限。锁的粒度按端口维度，不要设置全局锁，否则多台设备会互相阻塞。读取超时时间建议设为 5 秒，3 秒对于血压计充气测量通常不够，10 秒又会拖慢定时抓取任务。还要在程序退出钩子里调用释放端口的方法，防止重启后端口被占用报PortInUseException。

5.3 凌晨 3 点的预警短信把家属吓醒

现象：家属凌晨被短信震醒，内容是老人血压 158/95，点开细看并无大碍，第二天致电投诉“你们系统是不是有问题”。

原因：夜间的单次偏高值被按白天的阈值标准直接推送了。从生理规律看，夜间血压比白天低 10% 到 20%，158 的收缩压对很多老人来说处在夜间偏高但不算危险的范围。设备误差也可能制造这种偶发高值，比如老人睡觉时翻身压住袖带。

解决：调整预警策略，夜间只推危险级，不推偏高；偏高值写入趋势库，次日 9 点做一次累计统计。短信文案也要说明是“自动监测数据，如有不适请就医”，不能直接写“警告”这种容易引发恐慌的词。夜间危险级的判断阈值还要收紧，收缩压要大于等于 180 才推，老年人夜间血压超过 180 的情况较为罕见，一旦出现往往需要家属介入。

5.4 日志里时间差 8 小时：UTC 存储与本地时区

现象：查询某老人的测量记录时，发现数据库里保存的时间比实际测量时间晚了 8 小时，凌晨的测量记录都落在前一天。

原因：服务端以 UTC 时区运行，数据库连接串里没有设置serverTimezone，MyBatis 存入DATETIME时把本地时间转成了 UTC。查询时又按照服务器默认时区转回来，一来一回时间就乱了。

解决：统一约定。数据库连接 URL 里显式加上serverTimezone=Asia/Shanghai，Jackson 序列化 JavaLocalDateTime时指定Asia/Shanghai，Redis key 里记录的日期也统一用LocalDate.now()，不依赖服务器默认时区。如果源码里用的是Date而不是LocalDateTime，处理起来会更麻烦，因为Date本身不携带时区信息，格式化时全凭运行环境。

5.5 手机号自动绑定把老人数据绑给了错误家属

现象：家属在小程序里输入老人手机号，系统自动匹配后显示的是另一位老人的数据，数据串户。

原因：老人登记的手机号可能同时被多个家属绑定，或者老人本人没有手机、用的是家属副卡，手机号在运营商侧没有做到一一对应。自动匹配逻辑只按 mobile 字段精确匹配，必然会出现多对多时的错绑。

解决：取消自动绑定，改为“手机号匹配 + 家属确认”。匹配到多个老人时返回候选列表，让家属根据姓名和住址选择。绑定关系单独建一张elder_family_rel表，包含elder_id、family_account_id、relation_type三个字段，同一个老人可以被多个家属绑定，同一个家属也能关注多位老人，多对多关系在健康场景里才是真实存在的。绑定后还要提供“解除绑定”的能力，离婚、搬走的家庭成员需要能自己退出，否则后患无穷。

6. 源码到手后的验证路线：先跑通，再谈二次开发

源码到手后先按这个节奏走一遍，比看任何架构文档都有用。一套源码能不能作为二次开发的基础，核心不是它写得有多优雅，而是“能否在自己熟悉的机器上稳定跑起来”。跑通之后，我习惯性的进阶验证是构造一个模拟器，连续灌入 48 小时的假数据，观察晨峰预警时间段内的推送是否准确、是否出现重复推送。这一步能过，系统基本可以进入小范围试点。

三个值得投入的进阶方向：一是对接语音播报药盒，很多老人不识字，药盒上的指示灯和语音提醒比短信更直接；二是增加体检报告 PDF 的自动生成，社区养老站每月要打印老人的健康周报，这个功能能省不少人工；三是历史数据的趋势预测，老人连续三个月血压平稳，第四个月开始逐步升高时，提前提示家属带老人调整用药，这类需求在实践中远比“实时报警”更受家属认可。

我在多次接手类似源码项目后养成一个习惯：先跑起来再读代码，读代码时先看表结构和定时任务的边界，最后才看 Controller 层。这样能快速判断项目的真实完成度。希望这一篇能帮你在做老年人健康管理这条路上少走一些弯路，把你的时间花在那些真正影响老人安全的事情上，希望帮到你。

本文还有配套的精品资源，点击获取