直接使用 github.com/robfig/cron/v3 会 panic“invalid time zone”是因为其默认依赖 time.Local 加载系统时区，而 Docker 容器或某些 Linux 环境中 /etc/localtime 缺失或损坏，导致 time.LoadLocation 失败；解决方法是显式指定时区，如 cron.New(cron.WithLocation(time.UTC)) 或确保容器安装 tzdata 并设置 ENV TZ。
为什么直接用 github.com/robfig/cron/v3 会 panic：“invalid time zone”
常见于本地开发时没显式指定时区，而 cron/v3 默认使用系统时区（time.Local），但 Docker 容器或某些 Linux 环境下 /etc/localtime 缺失或软链损坏，导致 time.LoadLocation 失败。不是 cron 本身 bug，是时区加载失败的连锁反应。
解决方法很简单：
- 启动时显式设置时区：
cron.New(cron.WithLocation(time.UTC))（推荐用于生产） - 或确保容器镜像中存在时区数据：
apt-get install -y tzdata+ 设置ENV TZ=Asia/Shanghai - 避免依赖
time.Local—— 它在跨环境部署时不可靠
cron.AddFunc 和 cron.Schedule 的适用场景区别
AddFunc 是快捷写法，适合固定表达式 + 简单函数；Schedule 返回 cron.EntryID，支持运行时动态增删、暂停、手动触发，更适合需要控制生命周期的任务（如用户可配置的定时同步）。
例如：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// 动态添加并保留 ID，便于后续操作
id, _ := c.Schedule(cron.Every(5*time.Second), cron.FuncJob(func() {
fmt.Println("run now")
}))
// 后续可调用 c.Remove(id) 或 c.Entry(id).Job.Run()
注意：FuncJob 是 v3 新增类型，替代了旧版闭包捕获变量不安全的问题；别再用匿名函数直接传进 AddFunc 并在里面改外部变量，容易引发竞态。
如何让 cron 任务真正“准时”执行（误差控制在 100ms 内）
默认 cron 使用 time.AfterFunc 驱动，底层依赖 Go runtime 的定时器精度，通常误差在几十毫秒；但若任务执行时间长、GC 频繁或系统负载高，可能累积延迟。关键控制点有三个：
- 启用
cron.WithChain(cron.Recover(), cron.DelayIfStillRunning(cron.DefaultDelay))：防止前序任务卡住后续调度 - 避免在 cron job 中做阻塞 I/O（如未设 timeout 的 HTTP 请求、无缓冲 channel 发送）
- 如果对精度要求极高（比如金融对账），不要依赖 cron 做“触发”，改用外部调度器（如 k8s CronJob）+ 消息队列触发，cron 只做轻量轮询检查
替换 robfig/cron 的轻量替代方案有哪些
如果你只用到 @every 1h 或 @daily 这类简单语法，且不想引入第三方依赖，time.Ticker + time.ParseInLocation 手动对齐也能搞定：
ticker := time.NewTicker(1 * time.Hour)
go func() {
for range ticker.C {
now := time.Now().In(loc)
if now.Hour() == 2 && now.Minute() == 0 { // 每天 2:00 执行
doDailyJob()
}
}
}()
但注意：这种写法无法解析标准 cron 表达式（如 0 0 * * *），也不支持多时区、夏令时自动调整。真正需要 cron 语义（分、时、日、月、周组合）时，robfig/cron/v3 仍是目前最稳定、文档最全的选择。别为了“少一个依赖”自己重写表达式解析器——边界 case（如 2024-03-10 02:30 美国夏令时切换）极难处理。
