time.Ticker适合固定间隔轮询但不保证准时，仅确保两次Tick()调用间隔≥指定时间；任务超时会导致延迟累积或跳过tick，适用于健康检查等低精度场景，不适用于金融结算等严格定时场景。
time.Ticker 适合固定间隔轮询，但不保证准时
用 time.Ticker 做定时任务时，常见误解是“每 5 秒一定执行一次”。实际上它只保证「两次 Tick() 调用之间至少间隔指定时间」，如果任务执行耗时超过间隔，会累积延迟，甚至跳过某些 tick。
- 适用场景：状态轮询（如检查服务健康）、轻量级心跳、对精度要求不高的周期行为
- 不适用：金融结算、定时告警、依赖严格时间点的业务逻辑
- 关键参数：
time.NewTicker(time.Second * 5)创建后，需配合select和case 使用 - 必须调用
ticker.Stop()防止 goroutine 泄漏，尤其在函数提前返回或循环中断时
time.AfterFunc 是单次延迟执行，不是调度器
time.AfterFunc 常被误当成“定时任务启动器”，但它只触发一次，且无法取消已排队但未执行的任务（Stop() 只对未触发的生效）。
- 正确用法：
time.AfterFunc(10*time.Second, func() { doWork() }) - 错误认知：“调用多次
AfterFunc就能实现循环”——这会导致 goroutine 泛滥，且无统一生命周期管理 - 替代方案：若需重复 + 可控启停，应封装为自定义结构体，内部用
time.Timer循环重置
手动实现可停止的周期任务（不用第三方库）
标准库没提供开箱即用的“可暂停/恢复/取消”的调度器，但可用 time.Timer + for/select 组合安全实现：
func runEvery(d time.Duration, f func(), stopCh <-chan struct{}) {
ticker := time.NewTimer(d)
defer ticker.Stop()
<pre class='brush:php;toolbar:false;'>for {
select {
case <-ticker.C:
f()
// 重置 timer 实现等间隔（非 ticker 的累积误差模式）
ticker.Reset(d)
case <-stopCh:
return
}
}}
立即学习“go语言免费学习笔记（深入）”；
- 与
Ticker的核心区别：每次执行完立即重置Timer，避免因任务阻塞导致下一次延迟放大 -
stopCh推荐用context.WithCancel生成，便于上游统一控制 - 注意：如果
f()执行超时，仍会影响下次触发时间，需在f()内部做超时保护
time.Now().UnixMilli() 不是调度依据，只是时间戳工具
有人试图用 time.Now().UnixMilli() 轮询判断是否到点，这是低效且不可靠的做法：
- CPU 空转浪费资源，尤其在毫秒级精度需求下
- 系统时间可能被 NTP 调整、手动修改，导致判断逻辑错乱
- 无法响应外部停止信号，难以测试和调试
- 真正需要“绝对时间点触发”（比如每天 9:00 执行），应结合
time.Until计算下次等待时长，再用Timer等待
复杂调度逻辑（如 cron 表达式、跳过节假日）建议交由 robfig/cron 或 github.com/jasonlvhit/gocron 这类成熟库处理，标准库 time 包只负责“时间度量”和“基础等待”，不负责“任务编排”。
