用net.DialContext+context.WithTimeout做TCP探测比HTTP/health更快更准更可控，因其绕过DNS/TLS/HTTP栈、避免中间件干扰、直接验证端口连通性，且需全链路超时控制、状态去抖和心跳与业务deadline分离。
直接用 net.DialContext + context.WithTimeout 做 TCP 连通性探测，比 HTTP /health 更快、更准、更可控——尤其在内网集群中。
为什么不用 HTTP 做心跳检测
HTTP 心跳（比如 GET /health）看似简单，但实际埋了三颗雷：
- 依赖完整协议栈：DNS 解析 → TCP 握手 → TLS（若启用）→ HTTP 请求/响应解析，任意一环卡住都会拖慢判定
- 默认
http.Client会复用连接、自动重定向，可能把失败连接“缓存”住，掩盖真实故障 - 中间件干扰严重：Nginx、Envoy、云 LB 都有自己的超时逻辑，和你的 HTTP 心跳间隔稍不匹配，就会误判为离线
真正需要的不是“服务能返回 200”，而是“这个节点的 TCP 端口此刻可连通”。net.DialContext 一步到位，耗时通常在毫秒级，失败原因也更明确（dial tcp: i/o timeout 或 connection refused）。
必须用 context.WithTimeout 包裹整个拨号过程
只写 net.DialTimeout("tcp", addr, 500*time.Millisecond) 是危险的——它无法覆盖 DNS 解析阻塞。若 /etc/resolv.conf 配了不可达的 DNS 服务器，DialTimeout 可能卡住几秒才返回，彻底破坏心跳节奏。
立即学习“go语言免费学习笔记（深入）”；
正确做法是用 context.WithTimeout 兜底全链路：
ctx, cancel := context.WithTimeout(context.Background(), 600*time.Millisecond)
defer cancel()
conn, err := net.DialContext(ctx, "tcp", addr)
if err != nil {
// ctx.Err() == context.DeadlineExceeded 表示超时，无论卡在哪一环
return false
}
conn.Close()
return true
注意：超时值（如 600ms）要略大于 DialTimeout（如 500ms），确保 context 能真正生效。
状态变更必须加去抖（debounce）和最小间隔限制
网络抖动会让连续几次探测失败又恢复，如果每次失败都立刻标记 Down，再立刻恢复 Up，下游服务会反复重平衡，甚至触发雪崩。
每个节点应维护两个状态字段：failCount int 和 lastFailTime time.Time，并按以下规则更新：
- 探测失败时：若距上次失败 failCount++；否则重置
failCount = 1并更新lastFailTime - 仅当
failCount >= 3且time.Since(lastFailTime) 时，才触发 <code>Down事件 - 恢复逻辑同理：需连续 2 次成功，且间隔 > 500ms，才发
Up通知
这个设计能过滤掉绝大多数瞬时抖动，同时保证真实故障在 2–3 秒内被确认。
TCP 长连接场景下，别混用心跳与业务读写 deadline
如果你的服务本身维持长连接（比如 gRPC、自定义 TCP 协议），千万别用 conn.SetReadDeadline 来管心跳——它会影响所有后续业务读操作，一次心跳超时可能导致整个连接被误关。
正确方式是单独维护一个“最后心跳时间戳”：
- 客户端每 5s 发一次
ping，服务端收到后更新lastHeartbeatAt - 另起一个 goroutine，用
time.Ticker每 2s 检查一次：若time.Since(lastHeartbeatAt) > 15 * time.Second，则主动关闭该连接 - 这个检查逻辑和业务消息处理完全解耦，互不影响
真正难的不是写对一次心跳，而是让状态变更既及时又稳定——去抖阈值、超时配比、deadline 分离，这些细节一旦漏掉，高可用就只剩个名字。
