for循环中直接使用time.after会持续吃内存，因其每次调用等价于new timer并绑定goroutine和channel，gc无法提前回收未触发的timer，导致内存线性增长。
for循环里直接用time.After会持续吃内存
它每次调用都等价于time.NewTimer(d).C，新建一个*Timer实例，内部绑着一个goroutine和一个缓冲为1的chan time.Time。GC不会提前回收未触发的Timer——文档明确写着“The underlying Timer is not recovered by the garbage collector until the timer fires”。
- 高频循环（比如每秒100次）+ 长超时（如5 * time.Minute），每秒就堆100个待触发Timer，5分钟后才陆续释放，峰值内存线性增长
- 常见错误场景：HTTP handler内for-select轮询、Kafka消息消费loop、后台健康检查worker
- 现象包括：
runtime.NumGoroutine()持续上涨、pprof看到大量runtime.timerprocgoroutine、runtime.ReadMemStats().HeapObjects不断攀升、RSS几小时内飙到GB级
time.After返回的通道根本没法关也没法复用
time.After返回的是，即只读通道。你既不能<code>close()它，也不能往里写，更没法重置或判断状态。
- 试图在select之后手动关掉？编译报错：
invalid operation: close(ch) (cannot close receive-only channel) - 用
select { case 非阻塞读一次就想“丢弃”？没用——Timer goroutine和channel依然活着，资源照占不误 - 哪怕你从没读过那个channel的值，只要没超时、也没被Stop，它就一直卡在timer heap里
用context.WithTimeout替代最省心
它底层也用time.NewTimer，但cancel时自动调用Stop()，且ctx.Done()是只关闭一次的channel，多次接收无副作用。
- 适合有明确生命周期的场景：HTTP handler、RPC调用、带cancel控制的后台任务
- 语义清晰：“我最多等X秒”，天然融入cancel链，不用操心timer管理
- 示例：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，后续用select { case ，退出前<code>cancel()
手动复用*Timer必须检查Reset返回值
timer.Reset(d)返回bool：false表示Timer已触发或已被Stop。忽略它直接Reset，会导致timer.C积压未读时间值，后续select可能立刻命中旧值而跳过新逻辑。
- 正确模式：
if !timer.Stop() { ，再<code>timer.Reset(d) - 初始化时记得
defer timer.Stop()，或在所有退出路径显式调用timer.Stop() - 绝对不要写
timer := time.NewTimer(d); timer.Stop()——每轮仍新建Timer，毫无意义
真正容易被忽略的不是语法怎么写，而是泄漏发生得慢：heap_objects每天涨几百、goroutine数每小时+10，上线跑三四天监控才报警。等你grep出几十个散落在不同包里的time.After，修复成本远高于一开始用context.WithTimeout或统一初始化*Timer。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
