工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 presence 表示服务最近观察到的证据，不是永久事实。记录 expiresAt、instanceId 与连接数，读侧以服务端时间判断“在线、可疑、离线”三级状态。
实时后端必须在身份、顺序、背压和断线恢复之间给出一致语义。每条消息都要知道属于哪个会话版本、能否重放以及慢消费者达到上限后如何退出。
工程边界与取舍
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 心跳间隔加入随机抖动且租约至少覆盖数个周期；正常关闭发送 best-effort leave，多实例用原子计数避免关掉一个标签页就整机离线。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“在线状态不是布尔值：TTL、心跳与离线判定的工程边界”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 心跳与 TTL 设置相等会因一次调度延迟反复上下线；客户端时间参与过期判断还会被时钟漂移和篡改误导。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
把测试跑成闭环
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 冻结标签页、拔网线、杀进程、滚动重启服务并关闭一个并行标签页，逐项测量 suspect 与 offline 的判定时间。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。