应使用 time.ticker 实现可靠心跳，因其持续投递且可手动停止；需避免发送逻辑阻塞接收循环，须用 select + case 防止积压或跳过。
Go 里怎么用 time.Ticker 实现可靠心跳
直接用 time.Tick 做心跳容易丢信号，尤其在协程阻塞或 GC 停顿时；time.Ticker 才是正解，它能持续投递，且支持手动停止。
关键点在于：别让心跳发送逻辑阻塞 ticker 的接收循环，否则下一次 Tick 就会积压或跳过。
- 始终用
select+case ，别用 <code>for range ticker.C（后者在 channel 关闭后 panic） - 心跳发送失败（比如网络超时）不能影响 ticker 继续走，错误要单独 recover 或打日志，不能 return 或 break 主循环
- 协程退出前必须调用
ticker.Stop()，否则 goroutine 和 timer 会泄漏
ticker := time.NewTicker(10 * time.Second)
defer ticker.Stop()
go func() {
for {
select {
case <-ticker.C:
if err := sendHeartbeat(); err != nil {
log.Printf("heartbeat failed: %v", err) // 不 return
}
}
}
}()为什么 context.WithTimeout 不能直接套在心跳发送里
心跳本身是周期性探测行为，不是单次请求；如果给每次 sendHeartbeat() 套 context.WithTimeout，超时只会中断当次上报，但无法反映“协程已卡死”的真实状态。
真正要监控的是协程是否还在消费心跳信号 —— 所以健康检查逻辑应该独立于发送逻辑，靠外部观察 ticker 是否持续触发。
立即学习“go语言免费学习笔记（深入）”；
- 错误做法：在
sendHeartbeat()内部用ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)，这只能防发不出去，防不了 goroutine 挂住 - 正确思路：由另一个 watchdog 协程记录最近一次成功心跳时间，超时未更新就判定异常
- 注意
time.Now()调用本身不耗资源，但频繁打日志或写共享变量可能成为瓶颈，建议用原子操作更新时间戳
goroutine 泄漏的典型信号和定位方法
心跳协程没停，最直接的表现是 runtime.NumGoroutine() 持续上涨，或 pprof 查到大量处于 select 等待状态的 goroutine。
常见原因不是代码写错，而是没意识到某些 API 自带 goroutine（比如 http.Client 的 transport、grpc.Dial 的连接管理），它们内部的心跳也得统一管控。
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2看完整栈，重点搜ticker.C、time.Sleep、select - 所有
time.NewTicker必须配对defer ticker.Stop()，哪怕在 error 分支也要确保执行 - 别在 init 函数或包级变量初始化中启动心跳 goroutine —— 它们生命周期难管理，极易泄漏
生产环境心跳间隔设多少才合理
没有标准值，取决于你容忍的故障发现延迟和系统负载。太短（如 1s）会导致大量无效请求、GC 压力上升；太长（如 5min）等于放弃实时性。
实际中建议从 15~30 秒起步，再根据指标调整：若 99% 的心跳 RTT
- 不要用固定间隔硬编码，通过配置项或 flag 暴露，上线后可动态调优
- 心跳上报失败率 > 5% 时，先别急着调间隔，优先检查目标服务可用性或网络稳定性
- 多个服务之间的心跳节奏尽量错开（比如加个随机 jitter），避免秒级并发冲击
心跳机制看着简单，真正难的是把“协程还活着”这个模糊判断，转化成可观测、可验证、不自欺的信号 —— 很多时候问题不出在怎么发，而出在没人看它有没有被正常接收。
