Timer用于一次性定时，Ticker用于周期性定时；Timer的channel只发一次信号，Ticker则持续发送直至Stop；误用Ticker当Timer会导致逻辑错误。
Go 里 time.Timer 和 time.Ticker 不是“定时执行函数”的工具，它们只负责按时间发送信号——你得自己接住 channel 并处理逻辑，否则会漏触发、阻塞或 panic。
什么时候该用 Timer，什么时候用 Ticker
Timer 是一次性倒计时：启动后只向 C 字段的 chan time.Time 发一次信号；Ticker 是周期性节拍器：从启动起每隔固定间隔发一次信号，直到被显式 Stop()。
- 需要“5 秒后做一次清理” → 用
Timer - 需要“每 2 秒检查一次服务健康状态” → 用
Ticker - 误把
Ticker当Timer用（比如只读一次），会导致 goroutine 泄漏 —— 它还在后台持续发信号，没人收 - 反过来，用
Timer做轮询，就得每次Reset()，但要注意：如果旧 timer 还没触发就Reset()，它会先Stop()再重启，不会重复触发
Timer 的常见误用和修复方式
最典型错误是忽略 Timer 的可重用性与生命周期管理。它不是“用完即焚”，但也不是线程安全的，不能并发调用 Reset() 或 Stop()。
- 启动后不读
timer.C→ 定时器触发后，time.Time值会永久卡在 channel 中，下次Reset()或Stop()可能 panic - 在 select 中直接写
case 而不先timer.Reset()→ 第二次定时永远不会开始 - 并发调用
timer.Reset()→ 可能 panic：“timer already fired” 或 “send on closed channel”
timer := time.NewTimer(3 * time.Second)
// ✅ 正确：select 中收信号，并在需要时 Reset
go func() {
for {
select {
case <-timer.C:
fmt.Println("timeout!")
timer.Reset(3 * time.Second) // 下次再等 3 秒
}
}
}()
Ticker 的资源泄漏和停止时机
Ticker 启动后会持续往 C channel 发送时间值，**必须手动 Stop()**，否则 goroutine 和 channel 会一直存在，GC 不回收。
- 在
for range ticker.C循环中 break，但没调ticker.Stop()→ 泄漏 - 在
select中监听ticker.C，但程序退出前忘记Stop()→ 同样泄漏 -
ticker.Stop()后继续读ticker.C→ 永远阻塞（channel 已关闭，但没人发值） - 不要用
time.AfterFunc()替代Ticker做轮询：它是单次的，且内部用Timer实现，无法复用
ticker := time.NewTicker(1 * time.Second) defer ticker.Stop() // 确保退出前停止go func() { for { select { case t := <-ticker.C: fmt.Printf("tick at %v\n", t) } } }()
并发任务中怎么避免时间精度丢失和堆积
Go 的 Timer/Ticker 底层依赖系统调度，**不保证绝对准时**。尤其在 GC STW、高负载或大量 goroutine 竞争时，可能延迟数百毫秒甚至更久。更严重的是：如果你的处理逻辑耗时 > 间隔，Ticker 会“攒着”多个未消费的 tick，导致后续集中爆发。
- 对实时性要求高的场景（如游戏帧同步），别依赖
Ticker的“节奏”，改用自适应 sleep：time.Sleep(nextTick.Sub(time.Now())) - 用
select+default非阻塞读ticker.C，防止一次处理太久导致积压 - 不要在
ticker.C的接收逻辑里做阻塞 IO 或长耗时计算 —— 开新 goroutine 处理，但注意控制并发数 -
Timer的Reset()在 timer 已触发后返回false，记得判断返回值，否则可能误以为重置成功
真正难的不是调用 API，而是想清楚：这个定时信号是“提醒我该干活了”，还是“必须在这个时刻干完”。前者用 Ticker + 非阻塞处理，后者得结合上下文控制节奏，甚至放弃标准库 timer，改用基于 monotonic clock 的自定义调度器。
