Go中需用robfig/cron/v3等第三方库实现cron调度，因其支持秒级、时区、上下文取消及错误恢复；time.Ticker仅适用于固定间隔场景，无法表达复杂时间规则。
Go 里没有内置的“定时任务调度器”，time.Ticker 和 time.AfterFunc 只适合简单、单次或固定间隔的轻量触发，真要跑 cron 表达式、支持暂停/恢复、失败重试、分布式锁或任务持久化，得靠第三方库。
用 robfig/cron/v3 实现标准 cron 调度
这是目前最成熟、文档最全的 Go cron 库，兼容 Unix cron 语法，支持秒级（加 Seconds 选项）、时区、任务上下文取消。它不依赖外部存储，所有调度都在内存中运行，适合单机部署场景。
常见错误是直接写 * * * * * 却没启用秒级模式——默认只支持分+时+日+月+周，5 字段不包含秒，结果任务每分钟只执行一次，且时间点不可控。
- 启用秒级：初始化时传入
cron.WithSeconds() - 指定时区：用
cron.WithLocation(time.UTC)，避免服务器本地时区导致调度偏移 - 任务函数必须无阻塞；若需长时间操作，请启动 goroutine 并自行处理 panic 和超时
package mainimport ( "fmt" "log" "time" "github.com/robfig/cron/v3" )
func main() { c := cron.New(cron.WithSeconds(), cron.WithLocation(time.UTC))
_, err := c.AddFunc("0 30 * * * *", func() { fmt.Printf("每小时第30秒执行: %s/n", time.Now().Format("15:04:05")) }) if err != nil { log.Fatal(err) } c.Start() defer c.Stop() select {} // 阻塞主 goroutine}
如何安全停止正在运行的定时任务
cron.Cron的Stop()方法会等待所有正在执行的任务自然结束，但不会中断它们。如果某个任务卡死（比如 HTTP 请求 hang 住），Stop()就会无限等待，导致进程无法退出。真正安全的做法是：在任务内部使用
context.Context控制超时，并配合sync.WaitGroup等待任务完成。
- 不要在
AddFunc中直接写长耗时逻辑；封装成带ctx参数的函数 - 注册时用
func()包一层，传入带超时的context.WithTimeout - 调用
c.Stop()前，建议加一个合理的 shutdown timeout（如 10 秒）
为什么不用 time.Ticker 替代 cron 库
time.Ticker 只能做固定间隔轮询（比如每 5 秒检查一次），无法表达“每周一凌晨 2 点”或“每月最后一天 18:00”这类复杂规则。硬编码判断逻辑容易出错，且难以维护。
典型误用场景：
- 用
time.Now().Weekday() == time.Monday+Ticker模拟“每周一”，但没考虑时区、跨天边界、首次触发时机，导致漏跑或重复跑 - 手动计算下次执行时间并 Sleep，一旦系统时间被 NTP 调整，可能跳过或提前触发
- 多个
Ticker共存时，goroutine 泄漏风险高，没有统一启停管理
结论：有明确 cron 需求时，别自己造轮子。用 robfig/cron/v3 或更轻量的 jobber（仅支持基础 cron 语法）更稳妥。
生产环境要注意的三个细节
本地跑通不等于线上可用。这三个点新手最容易忽略：
-
cron.WithChain(cron.Recover())必须加上，否则任务 panic 会导致整个调度器静默崩溃 - 如果程序需要热重启（比如 k8s rolling update），任务状态无法自动迁移，需结合外部存储（如 Redis）实现幂等或断点续跑
- 大量高频任务（如每秒 100+）会显著增加调度器 CPU 占用，此时应评估是否该降级为事件驱动（如消息队列触发）
定时任务不是“设好就完事”，它的健壮性取决于你怎么处理失败、超时和生命周期——尤其是当它凌晨三点悄悄挂掉的时候。