在实时通信、音视频推流、大模型逐字输出等场景下，客户端与服务端之间通常保持一条长连接通道。一旦这条通道因为网络切换、NAT超时或中间代理回收而静默中断，用户侧就会遇到流式内容突然卡住、进度条不动却未报错的情况。要解决这类流式中断，核心手段是心跳包机制与断线重连策略的配合。
什么是心跳包机制
心跳包机制是指通信双方在空闲或低频数据传输时，按照约定周期互相发送体积很小的探测报文，用来确认对方进程仍然在线、底层链路仍然可用。它类似于两个人每隔几秒互相点头示意，即便不说话，也能知道彼此没走开。在流式系统中，如果没有任何数据流动，很多网关会在几十秒到几分钟之间直接断开映射表，而应用层完全无法察觉。
心跳通常由客户端发起，服务端回应；也可以双向互探。报文内容可以是固定字符串如 ping 与 pong，也可以是带时间戳的 JSON。周期设置需要权衡：太短会浪费带宽和电量，太长则无法及时感知断链。常见做法是移动网络下每 15 到 30 秒一次，内网服务可放宽到 60 秒。同时应区分业务包与心跳包，避免把正常数据误判为保活信号。
心跳丢失的判定方式
单次心跳未收到回应不一定代表断线，可能是临时拥塞。因此工程上多采用连续丢失计数：例如连续 3 次心跳超时（每次超时时间为周期的两倍）才标记连接失效。这种容错能减少误杀。部分协议如 WebSocket 提供了 ping 帧和 pong 帧，底层已经封装了部分逻辑，但应用层仍建议自己做业务级心跳，防止代理层假连接。
另外，心跳包应当绕过普通消息队列的限流，优先发送。否则在高峰期心跳被排队延迟，会触发错误断线。一些团队把心跳间隔做成可配置，根据网络类型动态下调，在地铁、电梯等弱网环境自动切换到更频繁探测，离开后恢复，从而兼顾稳定与开销。
断线重连应如何设计
断线重连是指当连接被确认中断后，客户端自动尝试恢复通信，而非依赖用户手动刷新。良好的重连不是简单死循环重试，而要具备退避、上限与状态恢复能力。否则在网络彻底故障时，海量客户端以固定频率冲击服务端，会引发雪崩。
最基础的策略是指数退避：第一次失败等 1 秒，第二次 2 秒，第四次 8 秒，直到最大如 30 秒后改为固定间隔。同时记录重连次数，超过阈值可提示用户检查网络。重连成功之后，不能假定从头开始，而应携带上次收到的序列号或偏移量，让服务端补发遗漏的流片段，这就是会话续传。
重连中的状态保持
流式中断常发生在用户观看直播、接收文件分片或 AI 生成答案的过程中。若重连后服务端丢失了上下文，用户就会看到内容重复或跳变。因此服务端应为每个连接分配临时会话 ID，客户端重连时提交该 ID，服务端从内存或缓存中恢复推送位置。对于无状态服务，则可让客户端上报已处理到的消息序号，由服务端按序补推。
在代码层面，重连逻辑要与业务订阅解耦。也就是说，网络模块只负责把连接修好，修好之后发出“通道就绪”事件，业务层再重新发起订阅请求。这样即使更换了 IP 或实例，上层也不需要重写。配合心跳机制，就能在用户无感的情况下平滑跨越网络波动。
心跳与重连的协同实战
单独看心跳或重连都不难，难的是二者衔接。典型流程是：心跳模块发现连续超时，将连接状态置为断开并通知重连模块；重连模块启动退避定时器，同时暂停业务发送；连接重建后，先发送携带会话信息的握手包，服务端校验通过再恢复心跳，最后业务流继续。任何一步缺位都会导致半开连接或消息堆积。
下面用一个简化对比说明不同做法的差异：
| 方案 | 是否含心跳 | 重连策略 | 中断恢复表现 |
|---|---|---|---|
| 仅 TCP 长连 | 否 | 无 | 静默卡死，需手动刷新 |
| 心跳无重连 | 是 | 无 | 能发现断线但停滞 |
| 心跳加退避重连 | 是 | 指数退避加续传 | 秒级感知，用户无感恢复 |
常见误区与排查建议
不少团队把 TCP 本身的 KeepAlive 当成应用心跳，这是误区。系统级 KeepAlive 默认两小时才探测，且很多移动运营商会丢弃这类包。真正可靠的保活必须在应用层实现。另一个误区是重连时不带上下文，导致服务端当新用户处理，历史流作废。
排查流式中断时，建议先在客户端日志打印每次心跳发出与回收时间，再看重连触发点与网络切换记录是否重合。若心跳正常却仍中断，多为中间层伪造了 ACK；此时应缩短心跳周期或改用带业务含义的探测帧。把机制跑通后，流式服务的掉线投诉通常会下降七成以上。