推荐用tcp而非http：tcp心跳基于net.conn，延迟稳定、失败明确、不依赖http路由或中间件；http因协议栈开销大、tls握手慢、易被网关拦截，仅适合调试。
心跳探测该用 TCP 还是 HTTP？
Go 微服务集群里做节点探测，很多人第一反应是发 HTTP GET /health，但实际生产中更推荐基于 TCP 的轻量心跳。HTTP 带完整协议栈开销、TLS 握手延迟、连接复用不确定性，而 net.Conn 级别的短连接或长连接心跳，延迟稳定、失败明确、资源可控。
- 用
net.DialTimeout发起一次 TCP 连接尝试，超时设为500 * time.Millisecond，比 HTTP 更快暴露网络分区 - 不依赖服务端 HTTP 路由或中间件（比如某些网关会拦截
/health，但透传 TCP 流量） - 若已用 gRPC，可复用其
KeepaliveParams中的Time和Timeout，避免重复实现
HTTP 方式只适合调试或边缘服务——它掩盖了底层连接问题，比如 TLS 证书过期、反向代理缓冲导致的假存活。
心跳间隔和超时怎么设才不误判？
心跳不是越密越好。time.Second 级别探测在高并发集群里容易触发雪崩式重连；30s 又太迟钝，故障发现窗口过大。
- 推荐组合：
Interval = 3s，Timeout = 1s，连续3次失败才标记下线 - 这样单次探测失败不影响状态，但能保证
9s内确认节点失联，同时避免瞬时网络抖动误判 - 注意：若用长连接心跳（如写入固定字节 + 读响应），必须设置
conn.SetReadDeadline和conn.SetWriteDeadline，否则阻塞读会卡死整个探测 goroutine
别直接抄开源库默认值——Kubernetes 的 node-monitor-grace-period 是 40s，但那是针对 VM 规模；你的 Go 微服务 Pod 实例通常需要更快反馈。
如何避免心跳 Goroutine 泄漏？
常见错误是每个探测目标启一个无限循环 goroutine，没做退出控制：
go func() {
for {
sendHeartbeat()
time.Sleep(interval)
}
}()
这会导致服务重启或节点下线后 goroutine 永不回收。
- 必须绑定
context.Context，并在服务关闭时调用cancel() - 探测循环里用
select { case 退出 - 如果用
time.Ticker，记得在退出前调用ticker.Stop()，否则底层 timer 不释放
尤其注意：不要把心跳逻辑塞进 gRPC Server 的 Register 钩子或 init 函数里——那里没有 context 生命周期管理，极易泄漏。
集群视角下，心跳状态怎么同步才一致？
单节点心跳成功 ≠ 集群其他节点也认为它在线。如果各节点独立维护“邻居列表”，会出现脑裂：A 认为 B 存活，C 却认为 B 已掉线。
- 真实可用的做法是引入中心协调者（如 etcd 或 Redis），所有节点将心跳写入同一个 key，带
lease ID和 TTL - 或采用 gossip 协议（如 memberlist），靠随机传播+版本号解决状态收敛，但需处理
NodeID冲突和初始种子节点配置 - 纯去中心化场景下，至少要让每个节点对同一目标的心跳结果做“多数派投票”（比如向 3 个相邻节点发探测，2 个说不通才算下线）
最容易被忽略的是时间漂移——不同机器系统时间差超过 TTL，会导致 lease 提前过期。务必确保所有节点开了 chrony 或 ntpd 同步。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
