应选time.NewTimer()执行单次任务、time.NewTicker()执行重复任务；前者只触发一次并停止，后者按间隔持续发送时间值直至Stop()，混用会导致goroutine泄漏或资源浪费。
time.NewTimer() 和 time.NewTicker() 该选哪个？
触发单次定时任务用 time.NewTimer()，重复执行用 time.NewTicker()。两者底层都基于系统级计时器，但行为完全不同：time.NewTimer() 只发送一次 time.Time 到其 C 字段通道，之后就停了；time.NewTicker() 则按固定间隔持续发值，直到手动 Stop()。
常见错误是拿 time.NewTimer() 去做轮询——比如在 for 循环里反复 new，这会泄漏 goroutine 和系统资源。反过来，用 time.NewTicker() 做一次性任务又会导致不必要的后续 tick 被丢弃或阻塞。
- 单次延迟执行（如 5 秒后发通知）→
time.NewTimer(5 * time.Second) - 每 30 秒检查一次健康状态 →
time.NewTicker(30 * time.Second) - 需要精确控制启停时机（如暂停重连逻辑）→ 优先封装
time.Ticker并显式调用Stop()
怎么避免 timer/ticker 泄漏？
time.Timer 和 time.Ticker 都持有运行时资源，不显式清理会导致内存和 goroutine 持续增长，尤其在长生命周期服务中容易被忽略。
关键点：只要创建了，就必须确保 Stop() 被调用，哪怕只用一次。注意 timer.Stop() 返回 bool —— 如果 timer 已触发或已 Stop，返回 false，此时不能再从 timer.C 读取，否则可能阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 在 defer 中调用
timer.Stop()仅适用于函数内同步使用场景；异步回调（如传给 goroutine）必须由接收方负责 Stop - 对
ticker.C的读取必须配对ticker.Stop()，不能只靠作用域结束 - 如果用
select等待多个 channel，timer/ticker 触发后务必立刻Stop()，否则残留的 channel 仍可能被调度器唤醒
为什么 time.After() 看似简单却容易出问题？
time.After() 内部其实每次调用都新建一个 time.Timer，它适合极简的一次性等待，比如 select 中加超时分支。但它不提供 Stop() 接口，一旦创建就无法取消 —— 即使你没从返回的 channel 读取，timer 依然会运行到触发，然后被 runtime 回收。问题在于：高频调用（如每毫秒一次）会产生大量短命 timer，GC 压力明显上升。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型误用：在 for 循环里写 case ，等效于每轮都 new 一个 timer，且几乎全被丢弃。
- 替代方案：复用一个
time.Timer，每次触发后Reset()（注意 Reset 前要先 Stop，或用 timer.Reset 的返回值判断是否需 Stop） - 超时控制类逻辑（如 HTTP client timeout）直接用标准库已有机制（
context.WithTimeout），别手写time.After() - 真要 inline 写超时，确保只在低频、明确生命周期的上下文中用
time.After()
如何让定时逻辑可测试、可中断？
硬编码 time.Sleep() 或直接 new timer 会让单元测试卡住或不可控。核心思路是把时间源抽象成接口，用依赖注入替换硬依赖。
最轻量做法：把 time.AfterFunc、time.NewTicker 这类构造函数作为参数传入，测试时换为立即触发的 fake 实现。例如：
type Clock interface {
After(d time.Duration) <-chan time.Time
NewTicker(d time.Duration) *time.Ticker
}
// 生产用 realClock，测试用 mockClock（返回已关闭的 channel 或立即发送的 ticker）
更进一步，所有定时触发逻辑应通过 channel 通知，而不是直接调用业务函数——这样测试时可以向 channel 发送模拟事件，跳过真实等待。
另外，任何长期运行的 ticker 必须支持通过 context.Context 中断，否则无法优雅 shutdown。不要只监听 ticker.C，要用 select 同时监听 ctx.Done() 并在退出前 Stop()。
真正难的不是写对第一次触发，而是让第 1000 次触发时还能准确 Stop、不泄漏、不 panic、能被测试覆盖——这些细节藏在 Stop 的时机、Reset 的条件判断、以及 channel 读取的边界处理里。
