必须使用 time.Ticker 而非 time.AfterFunc 实现心跳，因其可持续投递、避免 goroutine 泄漏和 panic 停摆；time.Tick 不可停止导致资源泄漏，应使用 time.NewTicker 并配 defer ticker.Stop()。
time.Ticker 是唯一靠谱的定时器选择，用 time.AfterFunc 递归调用心跳函数会泄漏 goroutine、栈溢出、panic 后彻底停摆——这不是理论风险，线上已见多起。
为什么必须用 time.Ticker 而不是 time.AfterFunc
心跳本质是「持续探测」，不是「单次延时执行」。time.AfterFunc 每次回调后需手动重注册，一旦 sendHeartbeat() panic 或忘记重调，整个心跳链就断了；而 time.Ticker 启动即持续投递，只要不 Stop() 就不会丢帧。
-
time.Tick(10 * time.Second)看似简洁，但底层复用全局 ticker，无法Stop()，协程退出时 timer 和 goroutine 泄漏不可逆 -
time.NewTicker返回可管理实例，必须配defer ticker.Stop()（注意：defer 在 goroutine 内写才生效） - 别在
for range ticker.C里循环——channel 关闭后会 panic，永远用select { case
匿名协程里的心跳发送逻辑怎么写才不崩
匿名函数本身没毛病，问题出在它包裹的逻辑是否扛得住失败。常见错误是把网络 I/O 直接塞进主循环，一错就退出，心跳彻底消失。
- 所有 I/O 操作必须包
context.WithTimeout，超时只中断当次请求，不能return或break主循环 - 加
defer func() { if r := recover(); r != nil { log.Printf("panic in heartbeat: %v", r) } }()，防 panic 终止 goroutine - 错误只打日志，例如
log.Printf("heartbeat failed at %v: %v", time.Now(), err)，带时间戳便于定位是偶发抖动还是已失联 - 别在匿名协程里直接修改共享状态（如 map），先构造新值，再用原子操作或 mutex 替换
心跳内容该传什么、不该传什么
心跳不是状态同步，是轻量级存活信号。字段越少、序列化越快、传输越稳。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必传字段：
task_id（UUID 或 job ID）、timestamp（用time.Now().UnixMilli()，别转字符串）、status（"running"/"failed" 枚举） - 禁传字段：
progress_percent（精度高易频繁触发）、memory_usage（采集开销大、延迟不可控）、stack_trace（体积大、敏感、非本职） - 上报失败不重试——重试可能堆积，下次心跳自然覆盖；但要确保日志可查、监控能告警
goroutine 泄漏怎么快速发现和收尾
泄漏不是悄无声息的，最直接信号是 runtime.NumGoroutine() 持续上涨，或 pprof 查到大量卡在 select 等待 ticker.C 的 goroutine。
- 协程退出前没调
ticker.Stop()，timer 不释放，goroutine 不退出——这是 90% 心跳泄漏的根源 - 别依赖
defer ticker.Stop()写在函数开头，必须写在启动它的匿名协程内部（否则 defer 在外层函数返回时就执行了） - 连接关闭、任务结束、服务 shutdown 时，要显式通知心跳协程退出（比如通过
donechannel），再调ticker.Stop() - 测试阶段加一行
log.Printf("heartbeat goroutine exiting, %d left", runtime.NumGoroutine())，上线后删掉
真正难的不是写出发心跳的代码，而是让这个 goroutine 在 panic、网络抖动、进程优雅退出等各种边界下都不静默失效——所有健壮性细节都藏在 select 分支的兜底逻辑和 Stop() 的调用时机里。
