Go 定时任务用 time.Ticker 还是 cron 调度器：补偿、重叠与停机行为怎么选

给一个 Go 服务加定时任务时，最容易先写出的是 time.NewTicker：每隔一段时间跑一次，代码短，测试也直观。但只要需求变成“每天 02:30 执行”“错过一次要不要补”“上一次没结束时能不能并发”，它就不再只是一个计时器问题。time.Ticker 适合固定间隔，cron 调度器适合日历时间；补偿、并发和停机收尾则需要业务代码明确承担。

没有日历表达式、也不要求补偿时优先用 time.Ticker；需要整点规则、时区或日历语义时再选 cron，并额外设计重叠控制和停机策略。

先看任务到底属于哪一种时间

把任务描述成一句完整的业务需求，选型通常就清楚了。比如“每 10 分钟刷新一次汇率缓存”描述的是间隔；“工作日 18:00 汇总当天订单”描述的是日历；“上次失败后 5 分钟重试”描述的是重试策略，不能直接交给调度器替代。

这里别急着把 cron 当成“更专业的 Ticker”。两者解决的是不同层次的问题：前者描述日历触发点，后者描述时间间隔。真正影响稳定性的，往往是触发后怎么管理任务。

固定间隔任务：time.Ticker 的最小写法

缓存刷新、临时文件清理、健康检查这类任务，通常不关心某个自然日的具体时刻。使用 time.NewTicker 时，重点是给每次工作设置独立的上下文，并在服务退出时停止 ticker。

func runCacheRefresh(ctx context.Context, refresh func(context.Context) error) {
    ticker := time.NewTicker(10 * time.Minute)
    defer ticker.Stop()

    for {
        select {
        case 

这个循环的语义是“收到一个 tick 后处理一次”。如果刷新耗时 12 分钟，下一次 tick 到来时，代码仍在处理上一轮；通道不会为每个时间点无限积压。因此不要把 tick 数量当成业务账本。需要每次都补做时，应把任务写入队列或保存下一次待处理时间。

什么时候把任务改成串行锁

如果刷新操作不可重入，可以在循环外加一个运行标记，遇到上一轮未结束就记录一次跳过；如果每轮都必须完成，则更适合把触发和处理拆开，让队列保存待处理任务。两者都比在函数里悄悄开 goroutine 更容易核对。

日历任务：cron 的优势是表达“什么时候”

每天凌晨、每周一、工作日下班前，这些需求的核心是日历。cron 表达式可以把“分钟、小时、星期”写成规则，代码不必自己计算下一个自然日。以常见的 robfig/cron 为例，创建实例时应显式选择解析格式和时区，而不是依赖服务器默认时区。

loc, err := time.LoadLocation("Asia/Shanghai")
if err != nil {
    return err
}

scheduler := cron.New(cron.WithLocation(loc))
_, err = scheduler.AddFunc("0 30 2 * * *", func() {
    ctx, cancel := context.WithTimeout(context.Background(), 20*time.Minute)
    defer cancel()
    if err := buildDailyReport(ctx); err != nil {
        log.Printf("daily report failed: %v", err)
    }
})
if err != nil {
    return err
}
scheduler.Start()

这里的六段表达式依赖所选解析器的格式，不能把不同 cron 实现的字段数混用。上线前至少用一个固定时刻测试下一次触发时间，并把时区写入配置或初始化代码。否则开发机和生产机的默认时区不同，日志里常常只表现为“任务没跑”。

最容易漏掉的三个边界

错过触发后要不要补

服务停机期间，time.Ticker 不会记住错过的 tick；多数 cron 调度器也不会替你生成历史任务。是否补跑应该由业务定义：日报可以补，缓存刷新通常等下一轮，扣款或发券则要根据业务流水状态决定，不能用“启动后立即跑一次”的粗暴逻辑覆盖所有场景。

上一次没结束时是否允许重叠

对账、归档、同步这类任务一般不希望两轮同时改同一批数据。单实例可以用互斥锁或运行状态标记；多实例则要用数据库租约、Redis 锁或任务队列的消费权。锁必须带过期和持有者信息，释放失败时也能人工判断。

停机时如何确认任务收尾

收到信号后先取消根上下文，再等待当前任务退出，最后停止调度器。不要只调用 Stop 就认为业务函数已经结束；它通常只影响后续触发，不会抹掉已经开始的工作。停机日志应包含任务名、开始时间、结束时间和结果。

按约束做最后选择

如果任务只是“从现在起每隔一段时间做一次”，time.Ticker 的依赖少、语义清楚；如果规则需要固定时刻、星期和时区，cron 更省心。两者都不适合承载复杂重试、历史补偿和跨实例排他，这些能力应该由队列、状态表或锁服务提供。

• 选择 ticker：间隔稳定、允许错过、任务短小、实例内运行即可。
• 选择 cron：需要日历表达式、时区和多个固定时间点。
• 升级到队列：必须补偿、不能丢任务、需要退避重试或多实例协作。

上线验收可以只看四项：触发时间是否符合预期，长任务是否会重叠，停机是否留下半成品，失败是否能从日志或状态表重新定位。把这四项写成测试，定时任务才算真正落地。

常见问题

time.Ticker 会在任务执行期间累积很多次触发吗？

不要按“每个 tick 都会排队”的模型理解它。任务处理慢时，触发信号可能被合并或等待消费；如果业务要求每次都记账，应使用持久化队列或状态记录。

cron 能自动补执行停机期间的任务吗？

不能把补偿当成 cron 的默认能力。补偿要结合任务幂等性、业务日期和状态表单独设计，并在启动时明确是否扫描未完成记录。

多个 Go 实例都启动 cron 会怎样？

每个实例都可能触发一遍。单实例部署可以接受，多实例部署要加分布式锁、租约或改用集中式任务平台，并记录抢锁结果。

小结

time.Ticker 和 cron 的区别，核心不是库的大小，而是时间语义：一个偏固定间隔，一个偏日历规则。先理清错过是否补、任务能否重叠、停机怎么收尾，再决定调度器；如果这三件事已经超出单进程边界，就把触发和可靠处理拆成两层。