time.after 在循环内使用会导致 timer 泄漏；应改用 time.newtimer 配合 reset/stop 闭环管理，或优先用 context.withtimeout 封装自动清理。
for 循环里直接写 time.after 会持续吃内存
每次迭代都新建一个 time.timer 实例，它绑定 goroutine 和内部 channel，进入运行时时间堆后，gc 不会提前回收——哪怕你立刻 break 出循环，这个 timer 仍会活到超时那一刻。超时时间越长（比如 5 分钟），堆积越快；高频循环（如每秒几百次 select）下，几小时内 heap_objects 翻倍、rss 暴涨到 gb 级很常见。
- 典型现象：
go tool pprof显示大量runtime.timerprocgoroutine；runtime.ReadMemStats中HeapObjects持续上涨，NumGC频繁触发 - 根本原因：
time.After(d)等价于time.NewTimer(d).C，返回只读 channel，无法Stop、无法Reset、无法判断是否已触发 - Go 1.22+ 虽对短周期做了调度优化，但语义未变——泄漏风险仍在，不能依赖版本修复
用 time.NewTimer 替换时必须手动管理生命周期
time.NewTimer 可控，但不是“用了就安全”，漏掉 Stop 或乱用 Reset 一样会泄漏。关键在三步闭环：初始化 → 循环中重置 → 退出前停止。
-
timer := time.NewTimer(5 * time.Second)后，必须配defer timer.Stop()或在所有退出路径显式调用timer.Stop() - 循环内用
timer.Reset(5 * time.Second)，但要检查返回值：if !timer.Reset(...)为 true，说明 timer 已触发或被 Stop，此时需先尝试从timer.C接收（避免阻塞），再重建：timer = time.NewTimer(...) - 错误写法：
for { t := time.NewTimer(...); t.Stop() }—— 每轮仍新建 timer，Stop 只是白忙一场
更推荐用 context.WithTimeout 替代
它底层也用 time.NewTimer，但封装了自动 Stop 逻辑，且与 cancel 链天然集成，语义更清晰，适合 HTTP handler、RPC、带上下文的后台任务等场景。
-
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，之后用ctx.Done()替代time.After(...) -
ctx.Done()是单次关闭 channel，多次接收无副作用；cancel() 调用后自动清理 timer，无需手动干预 - 不适用纯长期轮询（如无 context 的监控采集 loop），因为 context 生命周期可能早于 loop 结束
全局超时场景下 time.After 必须提至循环外
如果目标是“整个循环最多等 N 秒”，而不是“每轮各自等 N 秒”，把 time.After 放在 for 外面是最低成本修正方式。
- 错误：
for range data { select { case → 每轮都开新 timer，超时逻辑失效 - 正确：
timeout := time.After(1 * time.Second); for range data { select { case → timeout 触发后 channel 关闭，后续所有 select 立即命中 - 注意：这种写法仅适用于“一旦超时就整体退出”的场景；若需继续处理已就绪消息，得配合
goto或标志位控制流程
真正容易被忽略的是 Reset 的返回值判断和 Stop 的调用时机——不是写了 timer.Stop() 就万事大吉，得确保它在 timer 真正释放前被执行，且在 Reset 失败后及时重建。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
