time.After 会导致 goroutine 泄漏，因为每次调用都新建 time.Timer，其内部 goroutine 和容量为1的 channel 会持续驻留内存，直至定时器触发或显式 Stop；而 time.After 返回的只读 channel 无法 Stop，导致资源无法及时释放，长期堆积引发泄漏。
time.After 不能 Stop，用它就等于主动放弃资源控制权；真正可管理、需 Stop 的只有 time.NewTimer 和 time.NewTicker。
为什么 time.After 会导致 goroutine 泄漏
每次调用 time.After(d) 都会新建一个 time.Timer，返回其 C 字段（）。这个 Timer 在触发后不会自动 Stop 或回收——它的 goroutine 和 channel 会一直留在 runtime 中，直到 GC 发现无引用。但问题在于：<code>time.After 返回的通道无法被 Stop，你连句柄都没有。
- 常见泄漏场景：在 HTTP handler 或 for 循环里频繁写
case - 现象：压测时
runtime.NumGoroutine()持续上涨，pprof -goroutine显示大量runtime.timerproc - 根本原因：旧的 Timer 没被显式取消，新 Timer 又不断创建，GC 无法回收（因为底层 timer 结构仍被 runtime.timer heap 持有）
time.NewTimer 必须显式 Stop()，且要检查返回值
timer.Stop() 不是“可有可无”的清理动作，而是防止泄漏的强制操作。它返回 bool：true 表示成功取消未触发的定时器；false 表示已触发或已被 Stop。
- 如果只在 select 的某个 case 里调
timer.Stop()，而其他分支（如ctx.Done()）退出时没调，就会漏掉 - 正确做法：所有可能的退出路径前都调一次，包括
return、break、goto，以及defer（但注意 panic 时 defer 不执行） - 若
timer.Stop()返回 false，说明timer.C已有值待读，必须消费一次，否则后续Reset()可能因缓冲区满而阻塞
示例：
立即学习“go语言免费学习笔记（深入）”；
timer := time.NewTimer(5 * time.Second)
defer func() {
if !timer.Stop() {
select {
case <-timer.C:
default:
}
}
}()
select {
case <-ctx.Done():
return
case <-timer.C:
fmt.Println("timeout")
}
time.NewTicker 停止后仍有残留 tick？这是设计使然
ticker.Stop() 只停止后续发送，不消费已排队的 tick。它的 C 是无缓冲 channel，但 runtime 内部有机制允许“多发一个”（避免竞态），所以刚 Stop 后立刻 <-ticker.C 可能拿到一个过期 tick。
- 典型错误：在 HTTP handler 里启 goroutine
for range ticker.C，handler 返回后 ticker 还在发 → goroutine 泄漏 - 安全做法：全局复用 ticker，生命周期与程序一致；或改用
time.AfterFunc+ 手动 cancel 控制 - 若必须清空残留：仅当确认无其他 goroutine 往
ticker.C写时，可用for len(ticker.C) > 0 {
什么情况下可以不用 Stop()
只有两个例外：time.After 和 time.AfterFunc。它们内部封装了 Timer，触发后自动清理，无需、也无法手动 Stop。
-
time.After(d)：适合一次性超时判断，语义清晰，但不可复用、不可取消 -
time.AfterFunc(d, f)：适合延迟执行函数，f 执行完即释放资源 - 更推荐的替代方案：
context.WithTimeout(ctx, d)，它底层也用 Timer，但取消由 context 统一管理，无需手动 Stop，也不怕漏
真正容易被忽略的是：即使 timer.C 已被接收过，只要变量还活着，就必须调 timer.Stop() —— 否则那个 goroutine 就卡在 runtime 里，等不到 GC。
