time.after 在高频循环中会引发内存泄漏；每次调用都创建新 timer，其 goroutine 和 channel 不被 gc 回收，直至触发或显式 stop，导致内存线性增长至 oom。
它确实会，而且泄漏是确定的、可复现的——只要在高频循环里无节制调用 time.After，内存占用就会随时间线性增长，直到 OOM。
time.After 在循环中反复创建 Timer 实例
time.After(d) 不是轻量函数，它底层等价于 time.NewTimer(d).C。每次调用都会新建一个 *time.Timer，而每个 Timer 内部持有一个 goroutine 和一个带缓冲的 chan time.Time（容量为 1）。
- 这个 goroutine 会一直运行，直到定时器触发或被显式
Stop() - GC 不会回收未触发的
Timer：文档明确写着 “The underlying Timer is not recovered by the garbage collector until the timer fires” - 假设你在每秒 100 次的 for 循环里写
，那每秒就堆 100 个待触发 Timer，5 秒后才陆续释放——峰值就是 500 个 Timer 同时驻留内存
只读通道无法手动关闭，也无法重用
返回的是 ，即只接收通道。你既不能 <code>close() 它，也不能往里塞值，更没法复用——每次调用都是全新实例。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 有人想“在 select 走完后手动关掉”，但编译直接报错：
invalid operation: close(ch) (cannot close receive-only channel) - 也有人试图用
select配合default去“非阻塞读一次然后丢弃”，但没用：Timer 已启动，goroutine 和 channel 依然活着 - 哪怕你从没从那个 channel 读过一个值，只要它没超时、也没被 Stop，它就一直占着资源
替代方案必须满足两个条件
真正安全的替代方式，得同时解决「不重复创建」和「能及时终止」这两个问题。
- 用
context.WithTimeout：它内部虽也用NewTimer，但 context 取消时会自动Stop()底层 Timer；且ctx.Done()是只关闭一次的 channel，多次接收无副作用 - 手动复用
*time.Timer：初始化一次，循环中用timer.Reset(d)；但必须检查返回值——若返回false（Timer 已触发或已 Stop），要先timer.Stop()再NewTimer，否则timer.C可能积压未读时间值，后续select卡住 - 绝对不要在 HTTP handler、worker loop、消息消费循环这类长期运行的热路径里调用
time.After
最容易被忽略的一点：泄漏不是“立刻爆炸”，而是温水煮青蛙——可能上线跑几天才被监控发现 heap_objects 持续上涨，此时代码里几十处 time.After 已经散落在不同模块里，定位成本远高于预防成本。
