I4.03.2push over a live connection设计
推送实时但依赖连接维持
别名: 推送 · WebSocket · server-sent events · 长连接
概念解释
推送让服务端在事实发生时把更新送过来，不必等客户端下一次来问。新鲜度可以落到事件延迟加网络，而不是半个轮询间隔。它依赖一条活着的连接：连得上，才实时；连接静默、被中间设备掐断、或进程被冻住，推送就变成「看起来还在线、其实已经停更」。
机制
通道（长轮询、Server-Sent Events、WebSocket 一类）把客户端登记成可投递的终点。事件在服务端一发生就可以出门，延迟的下限是网络，不是询问节奏。维持这条通道有自己的账：心跳、 NAT 超时、移动网络切换、系统对后台套接字的回收。心跳太疏，中间设备当连接死了；心跳太密，电量和流量回到轮询的浪费形态，只是换成了空包。
连接断开时，客户端仍显示着断开前的最后一帧。若界面继续装成「正在听」，人会把静默当成「没有新事件」。推送的产品问题往往不在连着的时候，而在从连着掉到没连着的那一拍有没有被说出来，以及重连之后有没有把缺口补上。重连补洞需要游标或版本，纯「再听新的」会丢掉断开期间的事件。
边界
防火墙、企业代理、部分公共网络会拆长连接，推送在这些环境里会一直失败，必须能退回询问，而不能只显示连接错误。电量敏感的移动端，操作系统会在后台冻结套接字，前台以为的「实时」在切走之后并不成立。接收端若处理不过来（事件比渲染快），推送会变成积压，界面要么丢掉中间态，要么被事件打卡；这时要的是合并与背压，不是更实时。单向广播（行情、人数）和双向会话（协作光标）对连接质量的要求不同，不能共用一条「断了就重连到死」的策略。
怎么落地
- 把推送用在事件密度高、延迟预算低于一轮询问的场景：会话、协作、进行中的任务状态。
- 连接状态要可见：连着、重连中、已离线。离线时不要继续假装会有新事件进来。
- 重连必须从断开前的游标把缺口补上，而不是只听之后的新事件；心跳间隔对准部署环境的 NAT 与系统后台限制。
- 验证：在一条推送正在工作的界面上切断网络。状态应在心跳超时内变成离线或重连，而不是仍显示「实时」。恢复网络后，断开期间产生的事件应出现，不能只出现恢复之后的。在禁长连接的网络上，应能退到询问而不是空转。