go 语言需借助 robfig/cron/v3 等库实现生产级定时任务，该库支持 cron 表达式、并发控制与 panic 捕获；暂停/恢复需通过 entryid 管理，手动触发直接调用函数，状态与重试需自行封装。
Go 语言本身没有内置的生产级定时任务调度器，time.Ticker 和 time.AfterFunc 只适合简单、单机、无持久化、无并发控制的场景；真要支撑业务级定时任务（比如每天凌晨同步数据、每 5 分钟检查一次状态、失败重试、任务暂停/恢复），得靠成熟库或自己封装一层可靠抽象。
用 robfig/cron/v3 实现基础定时调度
这是目前 Go 生态最稳定、文档最清晰的 cron 库，支持标准 cron 表达式、任务并发控制、panic 捕获、任务取消，且不依赖外部存储。
- 安装：
go get github.com/robfig/cron/v3 - 基本用法：创建
cron.Cron实例，用cron.AddFunc或cron.AddJob注册任务 - 注意时区：默认用本地时区，线上部署建议显式设置，比如
cron.WithLocation(time.UTC) - 避免 panic 崩溃调度器：库默认 recover，但你自己的任务函数里仍需处理关键错误（比如 DB 连接失败）
- 示例：
c := cron.New(cron.WithLocation(time.UTC)) c.AddFunc("0 0 * * *", func() { fmt.Println("daily cleanup") }) c.Start() defer c.Stop() // 必须调用，否则 goroutine 泄漏
如何让定时任务支持暂停、手动触发与状态查询
robfig/cron/v3 本身不提供运行时控制接口，需要自己包装一层。核心是用 cron.EntryID 做任务标识，并维护一个映射表。
- 注册任务时保存
cron.EntryID，例如：id, _ := c.AddFunc("*/10 * * * *", job) - 暂停/恢复：调用
c.Remove(id)即停；重新AddFunc即恢复（注意 ID 变了） - 手动触发：直接调用对应函数即可，无需调度器介入 —— 但要注意并发安全，比如加锁或用带上下文的 job 函数
- 状态查询：维护
map[cron.EntryID]struct{ FuncName string; Spec string; LastRun time.Time }，在c.JobWrapper中更新
任务失败后怎么重试 + 防重复执行
cron 库本身不处理失败重试，也不保证“恰好一次”。是否重试、重试几次、间隔多久，全由你的 job 函数决定；防重则必须引入外部协调机制。
- 重试建议：job 函数内用
for i := 0; i + <code>time.Sleep，失败时记录日志并返回，避免 panic - 防重复的关键是幂等性：比如用 DB 的
INSERT ... ON CONFLICT DO NOTHING或 RedisSET key value EX 300 NX做执行锁 - 不要依赖 cron 调度时间做去重判断（如“只执行今天第一次”），系统时间可能漂移或任务延迟触发
- 如果任务耗时可能超过调度间隔，务必用
cron.WithChain(cron.Recover(), cron.DelayIfStillRunning())避免堆积
什么时候该换用分布式方案（如 asynq 或数据库轮询）
当你的服务开始上多实例、要求任务不因某台机器宕机而丢失、或者需要任务优先级、依赖编排、历史追溯时，robfig/cron 就不够用了。
- 典型信号：运维反馈“昨天那条报表没生成”，查发现是调度节点挂了 2 小时
-
asynq是个好选择：基于 Redis，支持延迟队列、失败重试、Web UI、多 worker，job 本身还是 Go 函数，迁移成本低 - 自建轮询方案（如 PostgreSQL +
pg_cron或应用层定时 SELECT FOR UPDATE）更可控，但开发和运维负担明显上升 - 别过早分布式：单机
cron+ 健康检查 + 自动拉起，撑住初期几十个任务完全没问题
真正难的不是写个定时器，而是定义清楚“这个任务失败了算谁的问题”——是网络抖动？上游接口变更？还是你自己没处理好空指针？调度模块只是执行通道，它的健壮性最终取决于每个 job 函数里的防御性代码和可观测性埋点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
