床旁终端在弱网环境下的离线缓存设计，核心思路是“本地优先、增量同步、冲突可解”，先保证业务可用，再追求数据一致。
床旁终端这个场景,网络质量永远是不可控变量，护士推着设备车从护士站走到病房，信号可能从满格掉到一格；病房间的承重墙、楼层的屏蔽效应、AP切换的延迟，都会让设备瞬间断网，如果页面转圈、数据丢失，耽误的是真实诊疗时间。
离线缓存方案适合哪些床旁终端场景
不是所有床旁终端都需要复杂离线方案,先判断场景是否匹配。
适合引入离线缓存的典型场景
- 生命体征采集设备：设备需要持续记录患者的体温、脉搏、血氧数据，网络中断后数据仍要继续采集，并在恢复连接后补传。
- 移动护理PDA：护士在病床前执行医嘱、录入护理记录、扫描腕带核对身份，操作频繁且操作路径固定，对响应速度有硬要求。
- 床旁结算设备：病区结算涉及费用查询、医保校验、支付确认，弱网下直接放弃操作会拖慢出院流程。
不适合离线缓存的场景
- 实时会诊视频、高清影像调阅，这类场景对实时性要求极高，弱网下应该直接提示“网络质量差”而非缓存降级。
- 涉及多业务系统强一致性的操作,如跨科室的药品库存扣减，离线缓存会引入一致性问题，代价大于收益。
判断标准就是一条：这个操作能不能接受延迟写入？能，就做离线缓存；不能，就做好网络检测和降级提示。
床旁终端离线缓存的架构分层
床旁终端硬件配置普遍不高,CPU和内存资源有限，离线缓存方案要分层设计，避免一个组件拖垮整机性能。
内存缓存层
缓存当前会话高频使用的数据,比如患者基本信息、今日医嘱列表、常用药品字典。
推荐使用SQLite内存模式或LevelDB的MemTable结构，读写速度在微秒级，不产生磁盘IO，内存缓存设定最大容量限制（建议不超过100MB），使用LRU或LFU策略淘汰冷数据。
磁盘缓存层
持久化存储离线期间产生的业务数据和待同步的操作日志。
关键设计决策：
- 优先选择嵌入式数据库（SQLite），不需要独立服务进程，对系统资源占用极少
- 数据库表结构按业务域拆分,operation_log（操作日志）、patient_snapshot（患者快照）、vital_signs_buffer（体征数据缓冲）分开存储
- 单条记录大小控制在4KB以内,避免大字段拖慢磁盘读写
- 磁盘空间使用率超过70%时，自动清理已同步数据和超过保留期（建议7天）的冗余数据
业务语义层
这一层解决的问题是：知道什么数据该缓存，什么数据不该缓存。
划分依据：
- 强实时数据（如患者危急值）不缓存：缓存这类数据端到端延迟反而更大，且容易引起误判
- 会话上下文数据（如当前登录用户、当前选择科室）：缓存有效期设为30分钟
- 只读基础数据（如科室排班、药品列表）：缓存有效期设为24小时，服务器端推送版本号强制刷新
离线缓存的数据同步机制
这是整个方案的核心,离线缓存只是在极端情况下的兜底手段，数据最终要回到中央服务器，同步机制决定方案是否可用。
写操作先入本地队列
所有写操作在业务层分解为原子操作,写入本地operation_log表，每条记录包含：
- 操作类型（insert/update/delete）
- 目标表名和目标ID
- 操作数据（JSON格式）
- 生成时间戳
- 操作人、操作设备信息
本地队列采用FIFO顺序，配合条件字段（sync_status）标记已同步/待同步/同步失败状态。
增量同步策略
同步触发条件：
- 网络由弱网切换到稳定网络后自动触发
- 应用从后台切回前台时触发一次
- 用户点击“手动同步”按钮强制触发
- 定时器每5分钟检查一次待同步队列,有数据且网络状态达标就执行
同步过程处理要点：
- 客户端将待同步记录按时间批量上传,每批次不超过100条
- 服务器接收后逐条校验,返回逐条处理结果（成功/业务校验失败/冲突）
- 客户端收到结果后,将成功的记录标记为已同步，失败记录进入冲突处理流程
- 重试机制采用指数退避策略，重试间隔从1分钟开始，最大间隔不超过30分钟，重试上限为5次
冲突处理设计
冲突主要发生在两端同时修改同一数据。
冲突处理规则按优先级排序：
| 优先级 | 冲突类型 | 处理策略 |
|---|---|---|
| 高 | 服务器数据版本号高于本地 | 以服务器数据为准，本地修改转存为变更记录 |
| 中 | 本地有操作但服务器数据被删除 | 保留本地修改并标记“待人工确认”，在界面上提示护士重新确认 |
| 低 | 同一字段两端都修改 | 以服务器端修改时间为准，合并时保留服务器内容 |
这个规则可以覆盖大多数实际情况,也是行业内的主流做法，对床旁终端这种以“记录类操作”为主的场景，冲突发生概率本身就不高，复杂规则反而增加维护成本。
弱网识别与网络状态管理
不会自动识别弱网的离线方案,用户体验等于没有，先说识别，再说策略。
网络状态分级
将网络状态划分为四个等级：
- 稳定：RTT小于100ms，丢包率低于1%，信号强度高于-65dBm
- 弱网：RTT在100ms-500ms，丢包率在1%到10%，信号强度-75dBm到-65dBm
- 极差：RTT超过500ms，丢包率超过10%，信号强度低于-75dBm
- 离线：无网络连接或连接已断开
终端设备通过定期ping服务器（间隔2秒）自动计算RTT和丢包率，同时读取系统Wi-Fi信号强度值，综合判断当前等级。
不同网络等级下的降级策略
极差及以上状态下，开放所有离线缓存能力，UI界面提供“离线模式”标识，页面顶部以浅黄色横条提示“当前网络较弱，数据将离线保存”。
稳定状态下，关闭本地队列，所有请求直连服务器，同时将待同步队列清空，消耗的代价可能是在网络切换瞬间有少量延迟，但换来的是强一致性和无冗余操作。
弱网状态属于模糊地带，采用“读走缓存，写走队列”的策略，界面感知是操作流畅的，但数据实际已进入本地队列，等待网络恢复后同步，这种策略的一个副产物是，部分操作延迟同步会让其他终端看到的数据不是最新的，但对床旁终端场景来说，短暂的数据延迟通常可以接受，例如医嘱执行记录的补传。
系统还会记录网络状态历史数据,便于运维团队后续优化病房AP部署位置，行业共识认为，医院无线网络的主要问题往往是AP漫游配置而非信号盲区，这些历史数据能辅助排查。
离线缓存与服务器端的一致性保障
离线缓存做得再好,如果服务器端验证逻辑不完善，同步时还是会出错，这是方案设计时容易遗漏的一环。
服务端需提供幂等接口
同一个操作被网络重试多次发送,结果必须一致，设计上，每个写操作在客户端生成全局唯一操作ID（UUID），服务端对操作ID进行去重判断，略过重复请求。
墓碑机制处理删除操作
床旁终端的离线删除操作不能真的删除记录,而是写入一条删除标记，服务端同步时识别删除标记，确认数据已被其他端引用时，返回一条“禁止删除，请先解除关联”的错误码，客户端将该记录移入异常列表，由护士在“操作失败”列表手动处理。
时间对齐问题
离线终端时钟可能出现漂移,直接使用设备本地时间作为业务时间，会导致多个终端数据排序错乱，解决方案是服务端返回一个
相对时间偏移量给客户端，客户端在写入操作日志时使用修正时间。
离线缓存问题排查的实操建议
网上讨论床旁终端离线缓存方案的帖子不少,但很多把方案停在理论层，这里分享实操经验，可直接复用。
排查本地缓存是否生效
- 在代码中开启SQLite日志模式（WAL），便于观察会话上下文和操作日志表的读写状态
- 在弱网环境下进入应用任意录入页面,输入一条测试数据，飞行模式保持5分钟，恢复网络后查看操作日志是否自动同步
- 检查
sync_status字段是否从0变更为1
排查同步失败的常见原因
- 请求超时：循环同步大批量数据时，单批次数据量过大导致处理超时，解决办法是缩小批次至50条以内
- 业务校验不通过：本地缓存数据与服务端业务规则不一致，例如药品批次已过期，同步返回错误码，数据流转至异常列表，需要人工处理，正常情况下这类数据应少报或不报
- 操作日志表膨胀：磁盘空间不足导致写入失败，设定定时任务每日凌晨自动清理已同步数据
弱网模拟与测试工具建议
- Android端使用OVERRIDE接口模拟弱网络,设置丢包率和延迟参数
- iOS端使用Network Link Conditioner做相同场景测试
- 自建Wi-Fi测试环境配置AP漫游场景，验证终端在AP切换期间的缓存行为
常见问题
床旁终端离线缓存方案对硬件配置有什么要求？
Android系统推荐配置4GB内存起步,磁盘剩余空间不低于2GB，CPU四核以上能满足基本缓存需求，如果终端设备是两年以前的机型，建议优先升级内存容量，SQLite在内存不足时会增加GC频率，反而降低整体性能，iOS设备对内存占用控制较好，主要关注存储剩余空间。
离线缓存数据会占用多少存储空间？
常规使用规模下,每名患者每日产生的操作日志平均200-400条，单条约2KB，一个月累积量约20MB，考虑到图片、附件等多媒体数据，建议将缓存目录独立挂载，设置500MB的容量上限，超过后自动清理最早数据，这个容量规划对多数终端设备来说可以接受。
床旁终端的离线缓存设计,本质是把网络不可用当作常态，去构建一套兜底机制，核心结论不会变：本地兜底所有高频关键操作，增量同步确保最终一致，冲突规则清晰可执行，把这三件事做扎实，弱网环境下的床旁终端就能保持基本可用，不再受网络波动牵制。