直接用cron.new()会panic“invalid time zone”，因默认依赖time.local而docker或alpine镜像常缺失tzdata；生产环境应显式指定时区，如cron.new(cron.withlocation(time.utc))或time.fixedzone("cst", 86060)，避免使用time.loadlocation("asia/shanghai")。
直接用 cron.New() 会 panic “invalid time zone” 怎么办
不是 cron 包有 bug，是它默认依赖 time.Local 加载系统时区，而 Docker 容器或 Alpine 镜像里常缺 /etc/localtime 或 tzdata，导致 time.LoadLocation 失败。
- 生产环境最稳写法：
cron.New(cron.WithLocation(time.UTC))—— 简单、确定、不依赖宿主机 - 要按北京时间调度，别用
time.LoadLocation("Asia/Shanghai")（Alpine 里大概率 panic），改用time.FixedZone("CST", 8*60*60) - 如果必须用系统时区，确保基础镜像装了 tzdata：
RUN apk add --no-cache tzdata+ENV TZ=Asia/Shanghai
cron.AddFunc 和 cron.Schedule 该选哪个
AddFunc 是快捷入口，适合固定表达式 + 无生命周期控制的场景；Schedule 返回 cron.EntryID，才能做动态增删、暂停、手动触发——微服务里用户可配置的任务必须用后者。
- 用
AddFunc时，函数内 panic 会被 cron 自动 recover 并 log，但日志默认打到 stderr，线上没重定向就等于没日志 - 用
Schedule时，必须自己传cron.FuncJob，别再用闭包捕获外部变量，否则可能引发竞态 - 示例：
id, _ := c.Schedule(cron.Every(10*time.Second), cron.FuncJob(func() { /* ... */ }))，后续可用c.Remove(id)或c.Entry(id).Job.Run()
任务执行超时、堆积、goroutine 泄漏怎么防
cron 本身不设 timeout、不控并发、不自动 stop goroutine。这些都得你亲手补上，否则上线三天就 OOM。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 单次执行必须套
context.WithTimeout，别只设http.Client.Timeout—— DNS、TLS 握手阶段它管不了 - 耗时 > 间隔的任务，加
cron.DelayIfStillRunning链，避免并发冲撞；再配cron.Recover()防 panic 中断调度 - 所有
time.Ticker或time.Timer必须显式Stop()，尤其在服务 graceful shutdown 时，漏掉就泄漏 goroutine - DB 连接、HTTP 客户端、日志句柄等资源，禁止在定时函数里重复创建，必须全局复用
进程重启后任务状态丢失怎么办
cron 是纯内存态，挂了就全丢。微服务要求“哪怕重启也要补跑”，就得自己加层：持久化 + 幂等 + 分布式锁。
- 启动时查 DB/Redis 记录的
last_run_at，和当前时间比，差多久就补几轮（注意：补跑逻辑本身得幂等） - 多实例部署时，每次执行前用 Redis
SETNX抢锁，失败则跳过，避免重复执行 - 别指望 cron 自带“错过即补”——它的
@hourly是指“最近一个整点”，不是“每小时必须执行一次”，中间宕机就真丢了
真正麻烦的从来不是“怎么加个定时任务”，而是“怎么让它在故障、扩容、升级、网络抖动下还稳住”。时区、超时、持久化、分布式协调，漏掉任意一环，线上都可能静默出事。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
