连接存在不代表业务健康
TCP 状态仍存在时，远端应用可能已经无法处理请求。应用心跳可验证更接近业务层的可用性，但其意义取决于具体设计。只返回一个简单心跳，也未必证明数据库、会员接口和全部业务都正常。
Keepalive 与心跳作用层次不同
TCP Keepalive 用于探测某些闲置连接状态，应用心跳则由业务协议安排。它们都不是确保数据永不丢失的保证。是否启用、时间间隔及容忍次数由系统或应用实现决定，不应把某个默认值套用到所有设备。
超时是等待政策
连接超时、读取超时、整体请求超时可能分别存在。过短会把正常波动误判为失败，过长又可能拖延恢复并占用资源。应根据交互需求与实际网络分布设定，并考虑失败后是否可以安全重试。
故障排查关注空闲与切网
如果活跃使用正常、长时间闲置后失败，需同时检查 NAT、代理、系统省电和应用恢复机制。归巢的连接状态提示也不应代替目标应用的业务结果。保活不能修复所有服务端错误。
场景示例
某业务心跳正常，但付款请求失败，可能因为心跳没有访问相同依赖。一个“在线”标记不足以证明完整业务链路可用。
实践检查清单
- 区分连接、心跳与业务请求。
- 记录空闲多久后出现异常。
- 调整超时与重试前确认业务幂等性。
参考资料
以下为相关标准或背景资料。本文是独立技术说明，示例不代表归巢实测或功能承诺。
实际网络表现受地区、运营商、目标服务、协议实现与负载影响。归巢的具体功能、会员权益及可用线路，以当前客户端和正式服务说明为准。