应避免在 for 循环中直接使用 time.After，因其每次迭代创建新 Timer 且不自动清理，导致内存泄漏、goroutine 泄漏和 CPU 升高；正确做法是用 time.NewTimer + Reset + Stop 或 time.AfterFunc 配合 cancel 控制。
time.After 在 for 循环里会不断创建新 Timer
直接在 for 循环体内调用 time.after，每次迭代都会新建一个 *timer，但旧的 timer 并不会被显式停止——它仍在后台运行，直到超时触发并发送值到其内部 channel 后才自动回收。这意味着：内存持续增长、goroutine 泄漏、cpu 占用异常升高。
常见错误现象：go tool pprof 显示大量 runtime.timerproc goroutine；runtime.ReadMemStats 中 NumGC 突增或 HeapObjects 持续上涨；程序运行数小时后卡顿甚至 OOM。
-
time.After底层调用time.NewTimer，返回的 channel 无法取消，Timer 无法复用 - 即使循环很快退出（比如 break 或 return），已启动的 Timer 仍会存活至超时
- Go 1.22+ 对短周期
time.After做了部分优化，但不改变语义，泄漏风险仍在
替代方案：用 time.NewTimer + Reset + Stop
需要手动管理生命周期的场景，必须用 time.NewTimer 替代 time.After，并在每次迭代前调用 Reset，退出前调用 Stop。
典型使用模式：
timer := time.NewTimer(5 * time.Second)
defer timer.Stop() // 防止遗漏
<p>for {
select {
case <-ch:
// 处理业务
case <-timer.C:
// 超时逻辑
if !timer.Reset(5 <em> time.Second) {
// Reset 返回 false 表示原 timer 已触发且 C 已关闭，此时需重建
timer = time.NewTimer(5 </em> time.Second)
}
}
}-
timer.Reset是线程安全的，可被多个 goroutine 并发调用 -
timer.Stop必须调用，否则 Timer 不会释放；若在select中已从timer.C收到值，则Stop返回 true，表示成功阻止了后续触发 -
Reset返回false仅发生在 timer 已触发且C已被关闭后，此时必须新建Timer，否则下一次Reset无效
更简洁安全的选择：time.AfterFunc 配合显式 cancel
如果只是想“延迟执行某操作”，且该操作可被取消，优先用 time.AfterFunc + 自定义 cancel flag，避免 channel 泄漏。
立即学习“go语言免费学习笔记（深入）”；
例如心跳超时检测：
var mu sync.RWMutex
var stopped bool
<p>stop := func() {
mu.Lock()
stopped = true
mu.Unlock()
}</p><p>time.AfterFunc(30*time.Second, func() {
mu.RLock()
defer mu.RUnlock()
if !stopped {
log.Println("heartbeat timeout")
}
})</p><p>// ... later
stop()-
time.AfterFunc不返回 channel，无 goroutine 持有等待 channel 的开销 - cancel 逻辑由业务控制，不依赖 Timer 生命周期管理
- 注意：
AfterFunc的函数体可能在stop()调用后仍执行（竞态），所以要用读写锁或atomic.Bool判断状态
for-select 中真正需要“动态超时”时怎么办
当每次循环的超时时间不同（如根据请求头设置 per-request timeout），不能复用固定 Timer，也不能反复 new time.After。正确做法是：在 select 前构造新 Timer，并确保旧 Timer 被 Stop。
var timer *time.Timer
defer func() {
if timer != nil {
timer.Stop()
}
}()
<p>for _, req := range requests {
if timer != nil {
timer.Stop()
}
timer = time.NewTimer(req.Timeout)</p><pre class="brush:php;toolbar:false;">select {
case <-req.Ch:
// handle
case <-timer.C:
log.Printf("req %v timed out", req.ID)
}}
- 每次迭代前检查并
Stop上一轮的timer，防止残留 - 不能依赖
defer清理循环内变量，必须手动管理 - 如果循环中可能 panic，建议用
recover+ 显式Stop，或把 timer 管理封装进结构体的Close方法
实际排查时，先用 pprof/goroutine 看是否有堆积的 timerproc，再 grep 代码里所有 time.After( 出现在 for 内的位置——这些几乎都是泄漏点。Timer 的生命周期比表面看起来更“重”，稍不注意就拖垮服务。
