time.After 在循环中反复调用会堆积未触发的 Timer，因每个 Timer 持有 goroutine 和 channel，超时前无法被 GC，导致内存泄漏。
time.After 在循环里反复调用会堆积 Timer
每次调用 time.After(d) 都会创建一个新 Timer，它内部持有一个 goroutine 和一个 channel。如果在 for 循环中无节制使用（比如轮询超时判断），未触发的 Timer 会一直等到超时才被 GC 回收——而高频循环下，大量“待触发但永远等不到”的 Timer 就堆在内存里。
常见错误写法：
for {
select {
case event := <p>正确做法是复用单个 Timer 或改用 context：</p>
- 用
context.WithTimeout()替代：它只管生命周期，不暴露底层 Timer - 手动管理
Timer：初始化一次，用Reset()重置，注意Reset()前要确保 Timer 已停止或已触发 - 避免在热路径（如 HTTP handler 内部循环）中调用
time.After
time.NewTicker 必须显式调用 Stop()
time.Ticker 启动后会持续向其 C 字段发送时间戳，背后始终运行一个 goroutine。它不会因为变量离开作用域、函数返回或 panic 而自动停止——哪怕你只用了一次 range ticker.C，只要没调 ticker.Stop()，它就一直活着。
典型泄漏点：
- HTTP handler 中启 goroutine 用
ticker做周期检查，但 handler 结束后 ticker 还在发信号 - worker 启动时创建 ticker，但 worker 退出逻辑没覆盖
Stop() - 用
defer ticker.Stop()，但 goroutine panic 了——defer不执行
安全写法示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
timer.Reset(d)
- 每次
Reset()后都要检查返回值 - 为防 channel 积压，清空逻辑建议用带
default的select - 别假设 “刚 Reset 就一定没信号”——调度延迟、GC 暂停都可能导致信号已发出但尚未被读取
goroutine 里用 Ticker / Timer 必须监听 ctx.Done()
仅调 ticker.Stop() 不够。如果 goroutine 卡在 上，而外部已取消 context，它根本收不到通知，Stop() 虽然释放了资源，但 goroutine 本身还在阻塞——栈、闭包变量、调度器跟踪全留着。
必须把阻塞操作放进 select，且至少含两个分支：
（主逻辑）（退出信号）
漏掉任一，就等于给 goroutine 开了“永生门票”。尤其注意：
第三方库封装的定时逻辑（比如某些 metrics reporter）是否真正响应 ctx；http.Client.Timeout 不等于 context 超时，仍需显式传入 req.WithContext(ctx)。
最易被忽略的是：timer/ticker 生命周期和 goroutine 生命周期必须对齐。Stop 是资源清理，ctx.Done() 是控制流退出——二者缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
