Go 中用 cron 包需显式设置时区（如 time.FixedZone 或 time.LoadLocation）、统一用 AddFunc 并手动 recover、用 context.WithTimeout 控制执行超时、自行实现任务持久化与分布式锁以弥补 cron 内存态缺陷。
Go 里用 cron 包跑定时任务，别直接上 cron.New()
默认的 cron.New() 不带时区支持，本地时间跑着跑着就偏了——尤其部署在 UTC 服务器但业务逻辑按北京时间触发时，0 0 * * * 会真正在 UTC 凌晨执行，而不是你想要的东八区凌晨。
正确做法是显式传入时区：
- 用
cron.WithLocation(time.Local)（开发调试可接受，但依赖宿主机时区配置） - 生产环境更稳：用
cron.WithLocation(time.FixedZone("CST", 8*60*60))或time.LoadLocation("Asia/Shanghai") - 注意：
time.LoadLocation("Asia/Shanghai")在某些精简镜像（如scratch或 Alpine）里可能失败，因为缺 tzdata —— 要么换基础镜像，要么改用FixedZone
cron.AddFunc() 和 cron.AddJob() 别混用
前者只支持函数值，后者支持任意实现了 cron.Job 接口的类型。表面看都能加任务，但行为差异明显：
-
AddFunc的函数体如果 panic，cron会捕获并 log，但不会中断调度器 —— 这是好事，但日志默认输出到stderr，线上没重定向就看不到 -
AddJob要求你实现Run()方法，panic 不会被自动 recover，一旦出错整个调度器可能卡住（取决于 cron 版本和运行模式） - 推荐统一用
AddFunc，并在函数内手动加defer func() { if r := recover(); r != nil { log.Printf("job panic: %v", r) } }()
任务执行超时没处理？cron 默认不设 timeout
一个 HTTP 请求卡住 5 分钟，下一轮调度照常触发，积压任务越来越多，最终 goroutine 爆炸。
立即学习“go语言免费学习笔记（深入）”；
必须自己控制单次执行时长：
- 用
context.WithTimeout包裹实际逻辑，比如ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) - 别只靠
http.Client.Timeout—— 它不涵盖 DNS 解析、TLS 握手等前置阶段，全链路超时得靠 context - 执行完务必调用
cancel()，否则 context 泄漏 - 注意：
cron本身不感知 context，超时需在业务代码里主动判断ctx.Err()
重启时任务状态丢失？cron 本质是内存态调度器
它不持久化、不协调、不分布式 —— 进程一挂，所有定时规则全丢。这不是 bug，是设计使然。
如果你需要“哪怕进程重启也要补跑错过的任务”，就得自己加层：
- 记录上次成功执行时间戳到 DB 或 Redis
- 启动时检查间隔，差了多久就补几轮（注意幂等性）
- 若多实例部署，还得加分布式锁（比如用 Redis SETNX），否则同一任务被多个节点重复执行
- 别指望
cron自带“错过补偿”功能 —— 它连“是否已执行”都不记
真正复杂的调度场景，该切到 asynq + 定时 producer，或者用外部服务如 Quartz / Airflow。
