<p>cron.New()无法实现分布式，因其是纯内存调度器，各进程独立解析表达式、维护timer heap，无状态共享与执行权协商，导致“0 ”在10个副本上触发10次，本质为单机玩具而非分布式调度。</p>
直接用 cron.New() 无法实现分布式，它只是本地内存调度器，10个服务实例就会触发10次相同任务——这不是分布式，是并发误触发。
为什么 cron.New() 默认不是分布式的
cron.New() 创建的是纯内存调度器，每个 Go 进程独立解析表达式、维护 timer heap，完全不感知其他实例存在。它不共享状态、不协商执行权、不处理节点故障。“0 * * * *” 在 10 个副本上就会触发 10 次，哪怕你加了 Redis 锁，只要 cron 本身还在每个节点上“准时” tick，就注定高并发抢占、锁竞争激烈、失败率上升。
- 本质是单机玩具，不是分布式调度器
- 所有分布式语义（如“仅一个节点执行”）必须由上层逻辑保证，而非 cron 库本身
- 错误做法：
cron.AddFunc("0 * * * *", doSendDailyReport)—— 业务逻辑裸跑，无锁、无超时、无上下文控制
正确解耦：cron 只负责“触发”，不负责“执行”
把 cron/v3 当作本地时钟信号源，让它每分钟（或每秒）调一次协调函数，真正的执行逻辑包裹在抢锁、校验、运行、续租这一整套流程里。
- ✅ 正确模式：
cron.AddFunc("0 * * * *", func() { tryAcquireAndRun("send_daily_report") }) -
tryAcquireAndRun内部必须用context.WithTimeout包裹实际业务，防止 goroutine 泄漏 - 抢锁失败时不要重试——直接 return，等下一轮 tick 再试，避免瞬时打爆 etcd 或 Redis
- 所有 job 函数必须包一层
defer func() { if r := recover(); r != nil { ... } }()，否则 panic 会终止整个 cron loop
etcd lease 抢占的关键实操点
不用 Redis 也能做轻量级分布式共识，但 etcd 的 lease 必须用对，否则会出现锁失效、双写、任务漏跑。
立即学习“go语言免费学习笔记（深入）”；
- lease TTL 设为任务预期耗时的 2–3 倍（如任务通常 15s 完成，TTL 设 45s），太短易误释放，太长故障恢复慢
- 抢占必须用
clientv3.OpPut+clientv3.OpGet组成事务，原子判断 key 是否不存在再写入，否则竞态下多个节点同时写成功 - 续租要单独起 goroutine，且监听
lease.KeepAlivechannel 关闭事件——这是 lease 被 revoke 的唯一可靠信号 - watch 必须带
clientv3.WithPrevKV()，否则拿不到旧值，无法区分是自己释放还是别人抢走
时区、panic、超时这三座坑必须填平
哪怕分布式逻辑写对了，单节点上的基础配置错一点，整个调度就不可靠。
- 初始化
cron.New()时必须传cron.WithLocation(time.UTC)或cron.WithLocation(time.FixedZone("CST", 8*60*60))；time.LoadLocation("Asia/Shanghai")在 Alpine 镜像里大概率 panic - 所有
AddFunc的表达式必须匹配 parser：默认 5 段（分时日月周），要用秒必须显式传cron.WithSeconds()并写 6 段表达式（如"*/5 * * * * *"） - 表达式解析失败时，
cron.AddFunc()内部只 log 错误、不抛异常，容易漏掉；动态读取配置时，务必提前用cron.ParseStandard()校验
真正难的从来不是“怎么让任务跑起来”，而是“怎么确保它只跑一次、不卡死、不漏跑、出错了还能被发现”。这些细节藏在 etcd lease 的事务写法里，藏在 context timeout 的嵌套层级里，也藏在 Alpine 镜像里缺失的时区数据里——漏掉任何一个，都可能让凌晨三点的报表任务静默失败一整周。
