http健康端点比tcp心跳更适合微服务场景，因其能真实反映服务就绪状态；需绑定":8080"、避免耗时操作、仅检查本地ready状态；websocket需显式处理ping/pong；net.conn心跳须防goroutine泄漏并设合理deadline；多级状态判定可提升可靠性。
HTTP健康端点比TCP心跳更适合微服务
微服务场景下，优先用/health这类HTTP端点做存活判定，而不是裸TCP心跳。因为Kubernetes的livenessProbe、Nginx健康检查、Consul健康注册都直接消费HTTP响应，且能真实反映“服务就绪”而非“端口通”。监听"localhost:8080"会导致探针失败——必须绑定":8080"并返回200或503。
常见错误是把/health写成耗时操作：查DB、调下游、加载配置。这会让探针超时，引发误驱逐。正确做法是只检查本地状态，比如用sync.RWMutex保护的ready布尔值，由各模块（DB初始化完成、配置加载成功）主动调用SetReady(true, "")更新。
- 不要在
SetReady里加日志或网络调用，锁持有时间越短越好 - HTTP handler中只调
IsReady()，返回200或503，不带任何业务逻辑 - 启动时默认
ready = true，避免服务刚起来就被判为不可用
gorilla/websocket必须手动处理Ping/Pong
标准库和gorilla/websocket都不自动响应Ping帧。如果只设conn.SetKeepAlive(true)或依赖浏览器自动发Ping，连接大概率在60秒左右被Nginx静默断开——这不是代码bug，是机制没对齐。
必须显式设置：conn.SetPingHandler()用于接收Ping并触发SetReadDeadline刷新；conn.SetPongHandler()推荐设置，用于收到Pong后重置读超时。这两个handler运行在读协程中，不能做任何阻塞操作（如DB查询、日志写入）。
- 用
WriteControl(websocket.PingMessage, nil, time.Now().Add(5*time.Second))发Ping，不是WriteMessage - Ping间隔建议25秒，必须小于Nginx的
proxy_read_timeout（建议≥75s） - 每次
ReadMessage成功后，立刻调SetReadDeadline(time.Now().Add(60*time.Second))
net.Conn心跳要防goroutine泄漏和deadline误用
net.Conn不会自动感知对端静默断连，Read可能永远不返回错误。必须用SetReadDeadline配合应用层心跳包来探测，不能依赖OS级SetKeepAlive（默认2小时，中间设备常丢弃）。
心跳包应与业务数据共用同一连接，但解包逻辑要分离：收到固定标识（如[]byte{0x00, 0x01}）即视为心跳，跳过业务处理，并重置最后活跃时间。业务读循环和心跳监控应分goroutine运行，否则一个卡住会拖垮全部。
- 发送方每次
Write前设SetWriteDeadline(time.Now().Add(5*time.Second)) - 接收方超时窗口设为发送间隔的2倍，
Read返回os.ErrDeadlineExceeded就关连接 - 每个连接的读/写goroutine必须用
sync.Once确保conn.Close()只执行一次
多级状态判定比单次超时更可靠
单次心跳丢失大概率是网络抖动，直接下线会引发误判。应该引入三级状态：Alive → Suspect → Failed：一次超时进Suspect，连续2–3次无心跳才升为Failed。
更进一步，可维护滑动窗口记录最近5次RTT，若延迟突增3倍且持续，提前预警；再结合Prometheus采集的CPU、内存、磁盘IO等指标联动判断，避免仅靠网络层信号做决策。
状态变更必须原子更新，并通过Redis Pub/Sub或Etcd Watch广播，不能只改本地map。真正容易被忽略的是：读超时的刷新时机（每次读成功后立刻重设）、中间件timeout数值（Nginx/ALB必须对齐）、以及状态升级的连续性校验——这三处任一出错，心跳机制就形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
