Golang time Ticker和Timer如何选择_定时任务实现方式对比_技术教程

当任务需周期性重复执行时，应优先使用time.Ticker；它自动维持固定间隔的时间事件流，资源开销低，而time.Timer仅适用于单次延迟或需严格串行节拍的场景。

什么时候该用 `time.Ticker`，而不是 `time.Timer`

当任务需要「周期性重复执行」时，time.Ticker 是更自然的选择；而 time.Timer 本质是「单次延迟触发」，强行循环调用它（比如每次触发后重置）不仅冗余，还容易漏掉重置逻辑或引发 goroutine 泄漏。

time.Ticker 自动维持固定间隔的 time.Time 事件流，底层复用一个系统级定时器，资源开销低
time.Timer 每次 Reset() 都需重新注册调度，高频重置可能触发 runtime 定时器堆调整，有轻微性能抖动
若任务执行时间 > 间隔周期，time.Ticker 会「积压」未消费的 Time（缓冲区默认 1），可能造成突发并发；time.Timer 则天然串行，但需手动控制下一次触发时机

`time.Ticker` 的常见误用：不关闭导致 goroutine 和内存泄漏

time.Ticker 启动后会持续向其 C 字段发送时间值，即使没人读取，goroutine 也会一直运行。这是最常被忽略的资源泄漏点。

必须在不再需要时显式调用 ticker.Stop() —— 即使程序即将退出，也要确保调用
不能只靠垃圾回收清理：time.Ticker 内部持有活跃的 goroutine 和系统定时器句柄，GC 不会中断它
在 select 中监听 ticker.C 时，如果分支里发生 panic 或提前 return，Stop() 很容易被跳过 → 建议用 defer ticker.Stop() 包裹整个逻辑块

需要精确控制执行节奏？用 `time.Timer` 手动节拍更稳妥

当任务耗时不稳定、且你希望「上一次执行完，再等 N 秒才开始下一次」（即“执行完成 + 间隔”模式），time.Timer 比 time.Ticker 更可控。

time.Ticker 是「固定起点+固定间隔」，不管前一次是否完成，到点就发信号 → 可能并发堆积
time.Timer 可以在每次处理完后，计算「现在 + 间隔」再 Reset()，实现严格的串行节拍
注意：Timer.Reset() 在已触发或已停止状态下行为不同；Go 1.23+ 要求先 Stop() 再 Reset()，否则可能静默失败

timer := time.NewTimer(5 * time.Second)
defer timer.Stop()
for {
select {
case <-timer.C:
doWork() // 执行任务
// 重置为「现在 + 5 秒」，而非固定周期
now := time.Now()
timer.Reset(now.Add(5 * time.Second).Sub(now))
}
}