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