Go语言定时任务实现与实战教程

该用 time.Ticker 还是 time.Timer 取决于任务类型：周期性触发用 Ticker（须手动 Stop），单次延迟用 Timer（自动销毁）；务必结合 context 控制生命周期，避免 goroutine 泄漏和内存暴涨。

Go 语言里 time.Ticker 和 time.Timer 到底该用哪个？

多数人一开始写定时任务，直接上 time.Tick 或 time.NewTicker，结果发现程序跑着跑着内存涨、goroutine 泄漏、甚至 panic。根本原因：没分清「周期性触发」和「单次延迟执行」的语义差异。

time.Ticker 适合固定间隔轮询（比如每 5 秒查一次健康状态），但必须手动 Stop()，否则底层 goroutine 永不退出；time.Timer 是一次性倒计时，触发后自动销毁，想重复用就得重建。

• 需要「每隔 N 秒执行一次」→ 用 time.NewTicker，且务必在不再需要时调用 ticker.Stop()
• 需要「N 秒后执行一次」或「N 秒后执行，再延后 M 秒再执行」→ 用 time.NewTimer 或 time.AfterFunc
• 千万别在 for 循环里反复 time.After() 而不接收 channel → 会堆积大量未读 channel，引发内存泄漏

用 context.Context 安全控制定时器生命周期

硬编码 time.Sleep 或裸用 time.Ticker 最大的问题是：没法优雅退出。服务关闭时，正在运行的 ticker 若没被 Stop，会卡住 main 函数退出，或导致 goroutine 残留。

正确做法是把定时逻辑包进一个函数，并接受 context.Context，利用 ctx.Done() 触发清理：

func runPeriodicJob(ctx context.Context, interval time.Duration) {
    ticker := time.NewTicker(interval)
    defer ticker.Stop()
for {
    select {
    case <-ticker.C:
        // 执行实际任务
        doSomething()
    case <-ctx.Done():
        return // 上级主动取消，立即退出
    }
}
}

启动时传入带超时或可取消的 context，比如 context.WithCancel(parentCtx)，关停时调 cancel() 即可。

• 不要在 select 外层用 for range ticker.C —— 这种写法无法响应 cancel
• 如果任务执行时间可能超过 interval，考虑用 time.AfterFunc + 递归调度，避免堆积
• 高频任务（如 <100ms）慎用 ticker，系统调度开销可能反超收益

第三方库 robfig/cron 的真实适用场景

很多人一上来就引入 github.com/robfig/cron/v3，以为能替代所有定时需求。但它本质是「基于字符串表达式的 job 调度器」，不是底层定时原语的封装。

它适合：需要 cron 表达式（"0 */2 * * *" ）、多个异构任务统一管理、支持 job 日志/错误重试/并发控制等运维能力的场景。不适合：极简嵌入、无依赖要求、或需与 context 深度集成的模块。

• 默认使用 cron.WithSeconds() 才支持秒级精度（v3 默认从分钟开始）
• cron.AddFunc 注册的任务 panic 会导致整个调度器 halt，必须自行 recover
• 若只需「每 30 秒拉一次 API」，用两行 time.Ticker 更轻量、更可控

生产环境必须加的三道防线

本地跑通 ≠ 上线稳定。Go 定时任务在线上常因时区、时钟跳变、panic 传播等问题静默失败。

• 所有定时任务入口加 recover()，防止单个 panic 停掉整个 ticker：

  func safeJob() {
      defer func() {
          if r := recover(); r != nil {
              log.Printf("job panicked: %v", r)
          }
      }()
      doSomething()
  }

• 避免依赖本地系统时钟 —— 用 time.Now().UTC() 统一时区，尤其跨地域部署时
• 对关键任务加「执行时间监控」：记录每次开始/结束时间，超时则告警（比如 HTTP 请求 >5s 就标记异常）

最易被忽略的是：Ticker 的 C channel 在 Stop 后仍可能有残留值，所以 select 中一定要优先处理 ctx.Done()，而不是靠 default 或顺序判断。