time.After 在 for 循环中反复调用会导致 goroutine 泄漏，因每次新建 Timer 且旧 Timer 不自动停止，持续占用资源；正确做法是复用 timer 并配合 Stop() 和非阻塞读取 t.C 后再 Reset()。
time.After 在 for 循环里反复调用会泄漏 goroutine
直接在 for 循环体里写 time.After(1 * time.Second)，每次迭代都新建一个 Timer，但旧的 Timer 不会自动停——它还在后台等着往自己的 channel 发时间，哪怕循环已经 break 了。结果就是：goroutine 堆积、内存上涨、CPU 持续跑高。
常见现象：go tool pprof -goroutines 显示大量 runtime.timerproc；runtime.ReadMemStats 中 HeapObjects 持续上升；程序运行几小时后响应变慢甚至 OOM。
-
time.After底层调用time.NewTimer，返回的 channel 无法取消，Timer 对象也无法复用 - Go 1.22+ 对短周期
time.After有轻量优化，但不改变“每次新建 + 不自动回收”的语义 - 哪怕循环退出很快，已启动的 Timer 仍会存活至超时才释放，中间这段时间全算泄漏
Timer.Stop() 返回 false 不代表失败，但必须配合 channel 清理
timer.Stop() 返回 false 只说明 Timer 已触发或已被 Stop 过，不是出错了。很多人写成 if !t.Stop() { t.Reset(...) }，这会漏掉“刚触发但还没来得及读 t.C”的情况，导致下一次 select 立刻收到旧时间，逻辑重复执行。
正确做法是：先调 Stop()，再立刻从 t.C 尝试读一次（用 select + default 避免阻塞），确认通道为空，再决定是否 Reset()。
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
Reset()不是Stop()+NewTimer()的等价替代，它内部会先尝试Stop()，但不会清空已发送未接收的值 - 如果
t.C里还滞留着上一次触发的时间，Reset()后第一次会立刻拿到那个“过期值” - Go 1.15+ 起
Reset()允许对已触发的 Timer 直接调用，但老版本（如 1.14）行为未定义，建议统一先Stop()
用 time.NewTimer 替代 time.After 时必须显式 Stop
只要用了 time.NewTimer，就必须配对调用 timer.Stop()，哪怕只用一次。不调用就等于放任一个 goroutine 在后台无限循环发信号——而如果没人收，它就永远卡在 chansend 上。
典型错误写法：timer := time.NewTimer(d); defer timer.Stop() 看似安全，但如果 timer.C 已被触发且你没及时读，defer 时 Stop() 返回 true，但通道里那个时间还在，下次读就会误触发。
-
Stop()可重复调用，多次执行无副作用，放在defer最省心 - 若在
select中已从t.C收到值，Stop()返回true，表示成功阻止后续触发 - 真正危险的是：既没读
t.C，又没Stop()，Timer 就成了“幽灵 goroutine”
系统时间跳变会让 time.Since 返回负值，别拿它做超时判断
time.Now() 读的是 CLOCK_REALTIME，受 NTP 或手动调时影响，可能突然回拨或前跳。一旦发生，time.Since(start) 就可能返回负的 time.Duration——它不会 panic，但后续 if 判断（比如 if elapsed > timeout）会失效。
这类问题在健康检查、JWT 过期校验、rate limit 时间窗口中特别隐蔽：日志时间乱序、超时提前触发、缓存莫名其妙失效。
-
time.Now().UnixNano()和time.Now()底层同源，换写法解决不了跳变问题 - 真正抗跳变的是
runtime.nanotime()，返回单调递增纳秒数，适合计算耗时差 - 若必须用绝对时间（如 JWT 校验），至少加一层校验：
if elapsed ，但治标不治本
实际排查时，最常被忽略的是：Timer 泄漏和时间跳变这两类问题往往共存——比如某服务因 NTP 回拨导致超时逻辑错乱，开发者加了更多 time.After 做兜底，反而加剧 goroutine 泄漏，最终卡死在 GC 的 STW 阶段。定位要从 pprof -goroutines 和 runtime.ReadMemStats 同时入手，而不是只盯着业务逻辑。
