为什么需要心跳机制
想象一下你正在和朋友微信语音通话，突然对方没声音了，你也看不到任何提示，只能干等。这种“假死”状态在应用层通信中很常见。TCP 连接可能因为网络波动、设备休眠或中间网关超时而断开，但操作系统未必能及时通知上层应用。这时候，靠应用自己来判断连接是否有效就变得特别关键。
心跳机制就是用来解决这个问题的——它像是每隔一段时间轻轻拍一下对方肩膀，问一句“你还在线吗？”。
心跳机制的基本设计思路
在应用层协议中加入心跳，本质是约定一种轻量级的周期性消息交换。客户端和服务器按固定间隔发送心跳包，对方收到后回复确认，或者只是单向通知。如果连续几次没有收到回应，就可以认为连接已失效，主动断开并尝试重连。
比如你在开发一个即时通讯系统，用户上线后保持长连接。如果没有心跳，用户手机锁屏几秒后Wi-Fi切换或进入省电模式，连接可能被悄悄切断，服务端却还显示“在线”。等别人发消息时才发现根本送不出去。
常见的心跳实现方式
最简单的做法是定义一个心跳消息类型，在协议体中标识为 HEARTBEAT。例如使用 JSON 格式：
{"type": "heartbeat", "timestamp": 1712345678}客户端每30秒发一次，服务端收到后可以不做响应（单向），也可以回一个 ack：
{"type": "heartbeat_ack", "timestamp": 1712345678}如果客户端连续两次未收到 ack，就触发重连逻辑。
合理设置心跳间隔
心跳太频繁会浪费流量和电量，尤其对移动设备不友好；间隔太久又无法及时发现断连。通常建议在20~60秒之间。如果你的应用跑在弱网环境下，比如车载设备通过蜂窝网络上报数据，可以把间隔设为25秒，并允许动态调整。
有些场景下还可以结合网络状态变化做优化。比如 Android 应用监听到从 Wi-Fi 切换到移动数据时，主动触发一次心跳检测，提前发现问题。
避免误判：别把正常延迟当断连
曾经有个项目设置了10秒心跳，超时5秒就断开重连。结果在地铁隧道里频繁掉线重连，反而加重了服务器负担。后来改成30秒心跳+90秒超时阈值，配合退避重连策略（第一次等2秒，第二次4秒，最多到32秒），情况明显改善。
关键点在于：超时时间要大于最大预期网络延迟，不能比心跳间隔还短。
与底层 TCP Keepalive 的区别
有人会问，TCP 不是有 Keepalive 机制吗？为什么还要自己实现？
因为系统级的 TCP Keepalive 默认超时时间很长（通常是2小时），根本不适合应用需求。而且它工作在传输层，应用层无法感知具体行为。自己实现的心跳运行在应用层，可控性强，还能携带时间戳、设备状态等附加信息。
实际排查案例：心跳缺失导致的“幽灵连接”
某次线上报警，大量用户显示在线却无法接收消息。查看日志发现，这些连接已经数小时没有业务数据交互，但 socket 仍处于 ESTABLISHED 状态。进一步抓包分析，发现路由器 NAT 表老化清除了映射关系，而两端都没有检测到异常。
问题根源就是缺少应用层心跳。修复方案是在协议中加入 type=heartbeat 消息，服务端每45秒发送一次，客户端响应。连接超过90秒无任何消息（包括心跳）即视为失效。
上线后，“伪在线”问题基本消失，推送到达率回升到99%以上。
小改动，大作用
一个简单的心跳字段，往往能解决最头疼的连接状态不同步问题。它不像加密或压缩那样炫技，但在稳定性方面的作用不可替代。很多线上故障回头看，其实只需要加几行代码就能避免。