time.After在for循环中会持续泄漏内存和goroutine；因其每次调用等价于NewTimer(d).C，新建Timer并绑定goroutine和channel，GC无法提前回收，超时前大量timer堆积导致内存线性增长。
time.After 在 for 循环里会持续泄漏 goroutine
每次调用 time.After 都会启动一个新的 goroutine 来等待定时器触发，而这个 goroutine 在超时前不会退出。如果把它写在 for 循环里（尤其是高频或无限循环），就会不断堆积未结束的 goroutine，最终吃光内存或压垮调度器。
常见错误写法：
for {
select {
case <-time.After(1 * time.Second):
doSomething()
}
}这等价于每秒新建一个 goroutine 等待 1 秒，但上一个还没结束——因为 time.After 返回的是 <-chan time.Time，背后 goroutine 要等到通道被读取或超时才清理，而这里每次都是新建通道、旧通道永远没人读。
正确替代方案：用 time.NewTimer 手动控制
time.NewTimer 返回的 timer 可以复用，避免重复创建 goroutine。关键点是：每次循环结束前要 timer.Reset()，且必须确保上一次的通道已被消费（或已停止）。
立即学习“go语言免费学习笔记（深入）”；
- 首次要用
timer.C，后续用timer.Reset(d) - 必须处理“已触发但未读取”的情况：调用
timer.Stop()后再Reset更安全，但要注意Stop返回true表示未触发可安全重置；返回false表示已触发，此时需先从timer.C读一次再Reset - 更稳妥写法是统一用
select+default消费残留值（如果担心竞态）
示例：
timer := time.NewTimer(1 * time.Second)
defer timer.Stop()
<p>for {
select {
case <-timer.C:
doSomething()
timer.Reset(1 * time.Second) // 重置为下一次
}
}高频轮询场景下，优先考虑 time.Tick 或 context.WithTimeout
如果只是固定间隔执行（如心跳、轮询），time.Tick 更简洁，但它返回的是不可关闭的周期通道，不适合需要动态停启的逻辑；而 context.WithTimeout 更适合单次带超时的操作，不适用于循环等待。
-
time.Tick底层也是复用 timer，但无法手动 Stop —— 一旦创建就一直跑，所以只适用于整个程序生命周期内稳定的周期任务 - 若需条件性等待（比如“最多等 2 秒，但有信号就提前退出”），应把
timer.C和其它 channel 一起塞进select，而不是反复调用time.After - 注意：
time.Tick的 channel 是无缓冲的，如果接收端卡住，后续 tick 事件会丢失（不会堆积）
调试时怎么发现这类泄漏？
运行时 goroutine 数量异常增长是最直接信号。可通过 pprof 快速定位：
- 启动时加
_ "net/http/pprof"，访问/debug/pprof/goroutine?debug=2查看所有 goroutine 堆栈 - 搜索关键词
time.startTimer或runtime.timerproc，能看到大量相似堆栈 - 用
runtime.NumGoroutine()打点日志，观察是否随循环次数线性上涨
真正麻烦的不是写错，而是这种泄漏在低 QPS 下完全不显眼，一到压测或上线就突然 OOM —— 因为每个 time.After 背后都藏着一个长期存活的 goroutine，它不占 CPU，但占内存和调度元信息。
