最常见原因是忘了调用 cron.start()——cron.new()仅初始化未运行实例，必须显式启动；若main快速退出需阻塞；v3默认无秒位，v4默认支持秒；panic被默认recover但不报错；单实例并发安全；时区需显式设置。
为什么 cron.New() 启动后任务没执行？
最常见原因是忘了调用 cron.Start() —— cron.New() 只是初始化调度器，不自动启动。它返回一个未运行的实例，就像声明了一个 goroutine 但没 go 一样。
- 必须显式调用
cron.Start()，否则所有已添加的任务都处于“待命”状态，不会触发 - 如果程序 main 函数快速退出（比如没阻塞），即使调用了
Start()，进程也会直接结束，任务自然没机会跑 - 建议在
Start()后加select{}或监听信号，防止主 goroutine 退出
crontab 表达式里秒位到底要不要？
Go 的主流 cron 库（如 github.com/robfig/cron v3+）默认使用 Unix cron 格式：分、时、日、月、周 —— 没有秒位。但很多人从 Linux crontab 切过来，误加第 6 位导致解析失败，报错类似 invalid schedule format。
- v3 默认不支持秒，写
"0 * * * * *"会 panic；要支持秒得用cron.WithSeconds()选项初始化 - v4（
github.com/robfig/cron/v4）默认启用秒位，格式为秒 分 时 日 月 周，和 Linux 不兼容，迁移时容易漏改 - 生产环境建议统一用 v4，并明确写成
cron.New(cron.WithSeconds())，避免隐式行为差异
任务函数 panic 了，调度器会挂吗？
不会全挂，但默认行为是吞掉 panic 并继续调度下一次 —— 这看似友好，实则掩盖问题：你可能根本不知道某个任务已经连续失败了三天。
- 默认情况下，panic 被
recover()捕获，仅打日志（如果启用了 logger），不中断调度循环 - 若需强错误反馈，可传入自定义
Logger实现，或包装任务函数手动处理 panic，比如上报 Sentry / 写监控指标 - 注意：v4 中可通过
cron.WithChain(cron.Recover(logger))显式控制恢复策略，别依赖默认静默行为
多个定时任务共用一个 cron.Cron 实例安全吗？
安全，而且推荐。单个 cron.Cron 实例本身是并发安全的，内部用互斥锁保护任务列表，AddFunc() 和 Start() 都可被多 goroutine 调用。
立即学习“go语言免费学习笔记（深入）”；
- 不要为每个任务新建一个
cron.Cron—— 资源浪费，且时间精度可能互相干扰（尤其高频任务） - 停止单个任务用
Remove()或标记关闭，别调Stop()全局停止，除非真要整个下线 - 如果任务间有强依赖或需隔离资源（如不同 DB 连接池），才考虑拆实例，否则纯属过早优化
真正容易被忽略的是时区：默认用本地时区，但部署到 Docker 容器常没设 TZ 环境变量，结果任务按 UTC 跑，和预期差 8 小时。初始化时务必显式传 cron.WithLocation(time.UTC) 或对应时区。
