Appearance
push-miss-sync-recovery
1. 实验目标与工程要点
这个 shared 样板不依赖 Android / iOS 真机推送，而是用最小可读脚本证明一个核心判断：推送丢失不等于最终不同步。
它要帮助读者看清三条回流路径：
- 推送正常到达：客户端立刻感知并刷新会话
- 推送丢失：前台进入时主动补拉会话详情
- 多端查看：任意设备都能基于服务端真相源恢复结果
2. 深入原理与生活浅显比喻
2.1 生活浅显比喻
把推送看成“快递到达短信”，把服务端任务状态看成“快递柜里的真实包裹”：
- 收到短信，当然能更快去取件
- 短信丢了，不代表柜子里没有包裹
- 只要你后来主动去柜子查询，依然能取到真正的结果
所以推送是“提醒加速器”，不是“结果真相源”。
2.2 底层原理分析
录音转写、离线消息、异步生成纪要这类链路，服务端至少要维护：
- 任务 ID / 会话 ID
- 当前状态（
transcribing/done/failed） - 结果更新时间
- 客户端最近一次确认版本
只要这些状态在服务端闭环存在，客户端就可以通过：
- push 到达时的即时刷新
- App 回前台时的补拉
- 列表页周期性刷新
- 多设备重新进入会话
把最终状态收敛回来。
2.3 方案对比矩阵
| 方案 | 通俗比喻 | 底层原理 | 保证特性 | 吞吐性能 | 运行开销 | 适用场景 |
|---|---|---|---|---|---|---|
| 只依赖推送 | 只等快递短信 | 结果感知完全绑定消息到达 | 到得快时体验好 | 高 | 低 | 低风险提醒类 |
| 推送 + 前台补拉 | 短信 + 到柜查询 | 推送加速，前台进入主动对账 | 推送丢失也能收敛 | 中 | 中 | 录音转写、异步任务结果回流 |
| 纯轮询补拉 | 固定时间去柜子看 | 定时请求服务端状态 | 不依赖消息通道 | 低 | 高 | 没推送能力或内网场景 |
3. Android / 移动端实战场景与误配事故
3.1 实战场景
适合这些业务：
- 会议录音转写完成提醒
- 异步导出 PDF / 报表
- 多端聊天历史补齐
- 离线任务回写结果
3.2 常见误配与事故注意事项
- 把推送设计成唯一通知通道，结果用户重装或静音后永远看不到结果
- 客户端本地状态没有版本号，补拉后无法判断是否需要刷新
- 多端登录时没有服务端真相源，A 端已完成、B 端仍显示处理中
3.3 排障思路
先问三个问题：
- 服务端有没有保存最终状态和更新时间？
- 前台进入会不会主动补拉，而不是只等推送？
- 多端进入同一会话时，是否都能从服务端拿到同一份结果？
4. 实验源码与运行验证
关键源码
关键参数 / 开关
pushDelivered=true|false：模拟推送是否成功送达foregroundPull=true|false：模拟前台恢复时是否主动补拉secondDevice=true|false：模拟第二台设备进入同一会话
运行方式
bash
cd labs/shared/background-tasks/push-miss-sync-recovery
node push_miss_sync_recovery.mjs预期控制台运行输出
text
[server] job=done updatedAt=2026-08-05T14:00:00Z
[push] message lost, deviceA still shows transcribing
[foreground] deviceA pull session => synced
[multi-device] deviceB open session => synced