心跳保活自测关键在于“断得准、活得稳、抖不误判”：需用HTTP健康端点+独立client+多次失败判定，确保/health监听0.0.0.0:8080、无副作用、返回200；心跳函数须用context.WithTimeout包裹全链路，禁用重定向与连接复用；分层验证断连、假活、抖动；WebSocket需显式处理Ping/Pong并设读写超时。
直接跑通心跳保活自测，关键不是“连得上”，而是“断得准、活得稳、抖不误判”。用 HTTP 健康端点 + 独立 client + 多次失败判定，是最贴近生产环境的自测路径。
HTTP /health 端点必须返回 200 且无副作用
自测第一步不是写心跳逻辑，而是确认服务自身健康接口是否可靠：
- 端点必须监听
:8080（不能是localhost:8080），否则 Kubernetes 或 Consul 的探针根本连不上 - handler 中只调
IsReady()，返回 200 或 503；禁止查 DB、调下游、加载配置等任何耗时操作 - 启动时默认
ready = true，避免刚起来就被标记为不可用 - 用
curl -v http://127.0.0.1:8080/health手动验证，响应头含HTTP/1.1 200 OK且 body 极简（如{"status":"up"}）
心跳检查函数必须用 context.WithTimeout 包裹全链路
不用 context.WithTimeout 的心跳函数，跑几天就 goroutine 泄漏 OOM。time.After 是典型陷阱：
- 所有阻塞操作——
http.Do、net.Dial、conn.Write——都必须传入同一个ctx - 禁用重定向：
CheckRedirect: func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse } - 禁用连接复用：
&http.Transport{DisableKeepAlives: true}，避免失败连接滞留掩盖真实故障 - 不要复用
http.DefaultClient，每次心跳用新 client 或至少隔离 transport
模拟断连要分层验证：网络层、应用层、状态机
光看 “curl 能通” 不代表心跳保活有效。需逐层注入故障验证行为：
立即学习“go语言免费学习笔记（深入）”；
- 网络层断连：用
iptables -A OUTPUT -d 127.0.0.1 -p tcp --dport 8080 -j DROP拦截出向包，观察心跳是否在超时后报错（如context deadline exceeded） - 应用层假活：服务进程还在，但
/health返回 503 或卡住 —— 此时心跳应连续失败 3 次才触发下线，不能单次就判死 - 状态机抖动：快速启停服务（
kill -9 & sleep 0.5 & ./service），检查注册中心是否维持Suspect → Failed的升级节奏，而非反复闪退闪现 - 读超时漏设陷阱：如果服务端没及时响应，客户端未在每次
Read后重置SetReadDeadline，会导致后续心跳包被当成超时丢弃
WebSocket 场景必须显式处理 Ping/Pong
用 gorilla/websocket 时，SetKeepAlive(true) 完全无效。Nginx 默认 60 秒静默断连，必须对齐：
- 服务端必须设
conn.SetPingHandler()（哪怕空实现），否则不自动回 Pong - 客户端每 25 秒调
WriteControl(websocket.PingMessage, nil, time.Now().Add(5*time.Second)) - 每次
ReadMessage成功后，立刻调conn.SetReadDeadline(time.Now().Add(60*time.Second)) - Ping 间隔必须小于 Nginx 的
proxy_read_timeout（建议 ≥ 75s），否则连接必断
真正难的不是发心跳，而是让心跳失败时的反应符合业务语义：一次丢包不算死，三次超时才下线，恢复后要平滑重连，状态变更还得广播出去。这些逻辑一旦写错，自测时看不出，压测或上线后才爆雷。
