心跳机制的基本作用
在现代网络通信中，客户端与服务器之间的连接稳定性至关重要。比如你在用手机看直播时，主播突然卡住几秒又恢复，这背后可能就是心跳机制在起作用。它不像数据传输那样直接传递内容，而是像‘打招呼’一样，定期确认双方是否还在线。
心跳机制的核心目的，是防止连接因长时间无数据交互而被中间设备（如路由器、防火墙）断开。这类设备通常会清理闲置连接以节省资源，而心跳包就是告诉它们：这个连接还在用，别关。
典型实现方式
最常见的做法是客户端或服务端每隔一段时间发送一个轻量级的数据包，称为心跳包。接收方收到后返回响应，表示链路正常。如果连续几次未收到回应，则认为连接已断，触发重连逻辑。
例如，在 WebSocket 连接中，客户端可以每30秒向服务器发送一个ping帧，服务器立即回一个pong帧：
setInterval(() => { if (socket.readyState === WebSocket.OPEN) { socket.send(JSON.stringify({ type: 'heartbeat', timestamp: Date.now() })); }}, 30000);服务器端监听到该消息后不做复杂处理，只需原路返回确认即可。这种设计简单高效，不会给系统带来额外负担。
服务端如何应对高频请求
当客户端数量上升到百万级别，每个30秒发一次心跳，意味着平均每秒要处理上千个心跳请求。这时候不能让每次心跳都走完整业务流程，否则数据库和日志系统都会被撑爆。
合理的做法是将心跳处理剥离出主逻辑，用独立的轻量模块接收并快速响应。比如使用Nginx或负载均衡器前置过滤，或者在网关层直接拦截特定类型的消息，避免进入核心服务。
有些系统甚至采用双向心跳：不仅客户端发，服务器也主动探测。这样能更准确判断是哪一端出了问题。比如某次APP刷新失败，其实是本地Wi-Fi信号弱导致发不出心跳，而不是服务器宕机。
超时与重连策略
设定心跳间隔和超时时间需要权衡。间隔太短，浪费流量和电量；太长，故障发现不及时。一般建议在15~60秒之间，根据应用场景调整。移动端可适当拉长，减少耗电；金融交易类则需更敏感。
一旦检测到断线，客户端不应立刻疯狂重试。应该采用指数退避算法，第一次等1秒，第二次2秒，第三次4秒……逐步增加等待时间，避免雪崩效应。就像你打电话对方没接，总不至于一口气打十遍吧？
实际开发中，很多人忽略心跳包本身的异常处理。比如发送失败时是否计入失败次数？网络切换瞬间（从Wi-Fi切4G）是否清空计数？这些细节决定了用户体验的流畅度。