Timer.Stop() 有时不生效，根本原因是它仅在定时器未触发时返回 true；一旦进入触发状态（如已向 channel 发送 struct{}{}），Stop() 返回 false 且无法撤回该发送。
Timer.Stop() 为什么有时不生效？
根本原因不是 Stop() 有 bug，而是它只在定时器尚未触发时返回 true；一旦 Timer 已进入触发状态（哪怕刚进 channel 发送逻辑），Stop() 就会返回 false，且无法撤回已发送的 struct{}{} 到 C 字段。
常见错误现象：调用 timer.Stop() 后仍收到一次 ，导致重复执行或 panic。
- 正确做法是：每次从
接收前，先检查是否已被显式停止（例如用原子布尔标记） - 更稳妥的模式是统一用
select+case + <code>case ，配合 <code>context.WithCancel - 别依赖
Stop()的返回值做业务分支——它只是“尽力而为”的信号，不是同步屏障
Ticker.Stop() 后忘记 drain channel 会泄漏 goroutine
Ticker 的底层是持续向 C channel 发送时间戳的 goroutine，Stop() 只关闭发送逻辑，但若 C 中还有未读取的 tick，该 channel 会一直阻塞在发送端，goroutine 无法退出。
使用场景：短生命周期任务中频繁启停 Ticker（如健康检查、轮询配置）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须在
ticker.Stop()后立即消费完C中残留值，常用方式：for len(ticker.C) > 0 { <-ticker.C } - 如果不确定 channel 是否为空，用
select { case 非阻塞清空 - Go 1.21+ 可考虑用
time.AfterFunc替代简单单次定时，避免Timer生命周期管理问题
重置 Timer 时直接 NewTimer 会引发内存泄漏
反复调用 time.NewTimer() 创建新实例，却不显式 Stop() 旧实例，会导致旧 Timer 的 goroutine 和 channel 残留——Go runtime 不会自动回收仍在运行的 timer。
参数差异：Reset() 是唯一安全重用 Timer 的方法，但它要求 timer 已 Stop 或已触发过；对刚创建未启动的 timer 调用 Reset() 是允许的，但对已触发未 Stop 的 timer 调用会 panic。
- 推荐模式：声明为指针字段（
*time.Timer），首次用time.NewTimer()，后续一律用timer.Reset(d) - 重置前无需手动
Stop()——Reset()内部已处理 - 注意：Go 1.22 起
Reset()对已 Stop 的 timer 返回false，需检查返回值并按需重建（极少见）
Ticker 在高频率下触发不准且 CPU 占用飙升
Ticker 底层靠系统级定时器 + goroutine 循环驱动，当 time.Second / 100 这类高频（
性能影响：10ms 级 Ticker 在 4 核机器上可额外增加 5–10% CPU 使用率，尤其在容器环境易被限频反制。
- 替代方案：用
time.Sleep()+ 循环控制精度（适合无并发写入C的场景） - 更优解：改用
runtime.SetFinalizer或信号量 +time.Until()手动对齐，但复杂度陡增 - 底线原则：生产环境避免
Ticker间隔
最常被忽略的一点：Timer/Ticker 的 C channel 是无缓冲的，任何接收端卡顿（比如日志打满、锁竞争）都会让整个定时器 goroutine 阻塞，进而拖慢所有后续 tick —— 它不像 select 那样能跳过。这比内存泄漏更隐蔽，也更难定位。
