Go ticker 长时间运行后任务越来越漂移怎么办

定时任务跑几个小时后越来越晚，先别急着把 time.Ticker 的周期改小。Go 的 ticker 本身按固定周期产生 tick；真正造成“漂移”的，通常是任务执行时间、接收 tick 的延迟，或代码把“任务完成时间”当成了下一轮的起点。更重要的一点是：慢接收方不会得到无限积压的 tick，官方实现会调整间隔或丢掉来不及接收的 tick。

如果任务必须按墙上时钟对齐，就用“固定截止时间 + 当前时间判断”调度；如果任务只要求两次执行之间间隔一段时间，才适合“执行完成后再等待”。先决定错过的周期是跳过还是补偿，再决定是否使用 ticker。

漂移先看哪两个时间点

排查时同时记录 tick 携带的时间和任务实际开始时间。下面的示例只展示记录与判断方式，任务函数应替换成自己的业务逻辑。

ticker := time.NewTicker(period)
defer ticker.Stop() // 任务退出时停止发送，避免遗留调度资源

for {
    select {
    case tickAt := 

如果 lag 逐渐变大，说明任务开始得越来越晚，或者当前 goroutine 没有及时回到 select。如果 lag 不大但两次任务开始时间间隔不稳定，应继续看任务耗时、日志时间戳和是否存在其他阻塞。

为什么慢任务会让人感觉 ticker 在漂移

time.Ticker 的 channel 只负责交付时间事件，任务代码通常在同一个循环里同步执行。任务执行期间循环无法接收新的 tick；当任务超过一个周期，未及时交付的 tick 可能被丢弃。这样做避免了 channel 中堆满过期任务，却也意味着“每个周期都必须执行一次”这个要求不能交给 ticker 保证。

还有一种常见写法是任务结束后调用 time.Sleep(period)，或者用 time.After(period) 重新等待。它表达的是“本轮结束后间隔 period”，任务耗时会被加进周期，长时间运行时自然越来越偏离整点。如果需求是两次任务之间留出冷却时间，这种行为是正确的；如果需求是每 5 分钟对齐一次，就不是正确的模型。

用固定截止时间而不是任务结束时间推进

需要稳定周期时，可以用 time.Timer 等待下一个截止点。每轮都从上一个截止点加周期，任务变慢只会让当前轮变晚，不会把后续计划整体向后平移。

func runOnSchedule(ctx context.Context, period time.Duration, run func() error) error {
    next := time.Now().Add(period)
    timer := time.NewTimer(time.Until(next))
    defer timer.Stop() // 无论正常退出还是取消，都停止当前计时器

    for {
        select {
        case 

这里的“跳过”不是丢失业务数据，而是承认一次周期性快照已经没有执行价值。若每个截止点都必须处理，应把截止点转成队列消息，并设置最大补偿次数、队列容量和告警阈值，不要在单个 goroutine 里无限追赶。

上线前把三种延迟分开监控

至少记录计划时间、实际开始时间和任务结束时间：schedule_lag = startedAt - plannedAt，run_duration = finishedAt - startedAt，再统计跳过次数或补偿次数。不要只看“上一轮结束到下一轮开始”的间隔，因为它无法告诉你是任务变慢，还是调度点已经被整体推迟。

退出时用 ctx.Done() 打断等待；使用 NewTicker 时保留 Stop 仍然是清楚的生命周期表达。周期小于等于零不要传给 NewTicker 或 Timer.Reset。如果任务允许并发执行，还要额外限制 worker 数量，否则修复了时间漂移却制造了并发重入。

常见问题

time.Ticker 会把错过的 tick 补回来吗？

不会保证逐个补回。官方文档明确说明，慢接收方会通过调整间隔或丢 tick 来追上节奏；需要补偿时应自行建立有上限的队列。

为什么不用每轮重新创建 ticker？

若目标是固定周期，重新从 time.Now() 创建会把任务耗时加入下一轮，反而形成完成时间驱动的漂移。固定截止时间或单个 timer 更容易表达策略。

跳过过期轮次会不会漏数据？

会不会漏取决于任务语义。刷新缓存、采集当前状态通常可以跳过；账务、订单和不可重复消费的批次应把周期转换为可追踪的队列项，采用限量补偿并监控积压。

核对时可以直接查看 Go 官方 time 包中 NewTicker、Stop 和 Reset 的说明：https://pkg.go.dev/time。最终要修的不是 ticker 的“漂移参数”，而是任务完成时间、计划截止时间和过期处理策略之间的混用。