当任务需周期性重复执行时，应优先使用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)) } }
超短间隔（
无论 Timer 还是 Ticker，底层都依赖操作系统定时器精度。Linux 默认 CLOCK_MONOTONIC 分辨率通常为 1–15ms，Windows 更低。低于此阈值的间隔实际无法保证。
立即学习“go语言免费学习笔记（深入）”；
- 设置
time.Millisecond级别间隔时，实测可能合并触发或延迟累积 -
runtime.LockOSThread()无法提升定时器精度，它只绑定 goroutine 到 OS 线程，不影响内核定时器调度 - 真正需要微秒级响应（如高频采样）应考虑
epoll/kqueue或专用实时库，而非标准time包
复杂点不在选哪个类型，而在是否意识到：定时器只是信号源，真正的节拍控制权始终在你的逻辑里 —— 尤其当 doWork() 可能阻塞、panic 或耗时波动时，Stop() 和重调度的时机比类型选择更重要。
