生产环境应选 go-co-op/gocron：支持并发控制、单例模式、秒级 cron，默认单 goroutine 更安全；robfig/cron/v3 时区需显式配置，stop() 不立即生效，且非线程安全，动态增删须通过 channel 中转。
别直接用 time.Ticker 或裸 go 启动 goroutine 做调度，它们连最基本的任务失败重试、并发控制、动态增删都做不到，生产环境一跑就出 panic、内存泄漏或任务堆积。
选对库：robfig/cron/v3 还是 go-co-op/gocron？
新项目无脑选 go-co-op/gocron；老项目维护 robfig/cron/v3 可以，但别加复杂逻辑。
-
robfig/cron/v3的Stop()不保证立即生效，任务panic后整个调度器可能静默卡死 -
gocron默认单 goroutine 执行，支持WithLimitConcurrentJobs()和WithSingletonMode()，防重入更靠谱 - 两者都支持 cron 表达式，但注意：
gocron默认秒级（6 段），robfig/cron/v3需显式调cron.WithSeconds() - 如果必须兼容传统 5 段表达式（如
"0 0 * * *"），robfig/cron/v3更贴近习惯
时间不准？八成没设 time.Location
任务总比预期晚 8 小时？大概率是用了默认 UTC 时区，而不是本地时区。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须显式加载并传入：
loc, _ := time.LoadLocation("Asia/Shanghai")，再传给cron.New(cron.WithLocation(loc)) -
robfig/cron/v3不设WithLocation就是 UTC；gocron也一样，不指定就是time.Local，但time.Local在容器里常为空，不如显式指定可靠 - 别在任务函数里靠
time.Now().Hour() == 9判断触发时机——NTP 校时会导致跳过或重复
动态增删任务不能直接写 HTTP handler 里
cron.Cron 和 gocron.Scheduler 都不是线程安全的，HTTP 并发请求直接 AddFunc() 会 panic 或失效。
- 正确做法是用 channel + 单 goroutine 统一中转：
taskCh = make(chan TaskOp, 100)，所有增删操作走这个 channel - 那个常驻 goroutine 负责从
taskCh读取、校验、再调用调度器原生方法，避免并发冲突 - 如果只是临时触发某次任务（比如“立刻重试订单号 123”），用
job.RunNow()（gocron）或封装一个独立的触发 endpoint，别动调度规则本身
任务执行失败了怎么办？别指望自动重试
两个主流库都不内置重试逻辑。失败后默认跳过，不会指数退避，也不会记录重试次数。
- 必须自己封装 handler：在业务函数外加一层闭包，捕获 error / panic，按
MaxRetries和RetryDelay决定是否重推回队列 - 推荐用
time.AfterFunc()+ 递归调度替代Ticker，天然串行，避免因执行超时导致堆积 - 若用优先级队列（
container/heap），RetryDelay应随重试次数增长（如time.Second * time.Duration(1），防止雪崩 - 状态更新必须原子：别先查再 update，用带版本号的乐观锁或
UPDATE ... WHERE status='pending' AND version=old_ver
真正难的不是“怎么让任务跑起来”，而是“它挂了谁来兜底”“并发冲高时怎么不打爆下游”“重启后状态怎么续上”。这些细节不提前想清楚，上线后第一波流量就会暴露问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
