time.After在for循环中反复调用会导致内存泄漏，因其每次调用等价于NewTimer(d).C，新建Timer实例并绑定goroutine和channel，GC无法提前回收，超时前大量timer堆积致内存线性增长。
time.After 在 for 循环里反复调用会持续吃内存，不是“写法不优雅”问题，而是明确的资源泄漏——每次调用都新建一个 *Timer，背后绑着 goroutine 和 channel，超时前 GC 不回收。
for 循环中直接写 time.After 为什么危险
常见错误现象：runtime.ReadMemStats 显示 HeapObjects 持续上涨；go tool pprof 看到大量 runtime.timerproc goroutine；程序运行几小时后 RSS 突增至 GB 级别。
- 每次
time.After(5 * time.Second)都等价于time.NewTimer(5 * time.Second).C，无法 Stop、Reset 或判断状态 - 哪怕
select中另一路分支立刻返回（比如先关闭），这个 timer 仍会在后台跑满 5 秒才释放 - 高频循环（如每秒数百次的 HTTP handler 轮询）下，未触发 timer 堆积速度远超 GC 回收能力
用 context.WithTimeout 替代最省心
它底层也用 time.NewTimer，但生命周期由 context 自动管理，cancel 时自动 Stop()，不用操心 channel 是否读完、是否重置。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 语义清晰：“我最多等 X 秒”，天然适配 HTTP handler、RPC 调用等有明确上下文边界的场景
-
ctx.Done()是只关闭一次的 channel，多次接收无副作用，不会因漏读导致阻塞 - 错误写法：
select { case → 正确写法：ctx, cancel := context.WithTimeout(parent, 5*time.Second); defer cancel(); select { case
必须手动管理 Timer 时，timer.Reset() 的返回值不能忽略
timer.Reset(d) 返回 bool：false 表示 timer 已触发或已被 Stop()，此时若直接复用，timer.C 可能积压旧值，后续 select 会立刻命中造成逻辑错乱。
- 安全模式：先
if !timer.Stop() { select { case ，再timer.Reset(d) -
defer timer.Stop()只防正常退出，panic 时不会执行；长期运行的循环必须在每个退出路径显式timer.Stop() - 初始化一次
timer := time.NewTimer(0)后立即Stop()，避免首次Reset前状态不确定
真正容易被忽略的是：即使你记得 Stop()，若没检查 Reset() 返回值并清空 channel，timer 仍可能“假死”——表面没泄漏，但超时逻辑失效，且难以定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
