go标准库不支持cron解析，必须用cron.parsestandard（5字段unix格式）或parsequartz；调度器需显式start()，panic会导致停摆；withseconds()需6字段且切换为quartz解析器；须校验表达式、加recover链、显式设时区。
Go 标准库完全不支持 Cron 表达式解析，cron.ParseStandard 或 cron.ParseQuartz 是唯一可靠入口；调度器必须显式 .Start()，且任务 panic 会停摆整个调度循环——这不是配置问题，是设计事实。
如何用 cron.ParseStandard 正确解析 5 字段表达式
它只认标准 Unix 格式（分、时、日、月、周），不带秒，字段数必须严格为 5。少一段或多一段都会失败，空格错位也会静默失败。
-
cron.ParseStandard("0 30 * * *")✅ 合法：每天 30 分触发 -
cron.ParseStandard("0 0 * *")❌ 报错：expected 5 fields, found 4 -
cron.ParseStandard("0 30 * * *")❌ 失败：中间两个空格导致解析器截断 - 返回
*cron.Entry后，调Next(time.Now())才能拿到下次执行时间，不是立即执行
为什么 cron.WithSeconds() 必须搭配 6 字段表达式
v3 默认用 StandardParser（5 字段），cron.WithSeconds() 实际切换为 Quartz 风格 parser，此时表达式必须写满 6 段（秒、分、时、日、月、周），否则解析返回 nil，AddFunc 静默跳过注册。
-
cron.New(cron.WithSeconds())+"*/5 * * * * *"✅ 秒级生效 -
cron.New(cron.WithSeconds())+"0 * * * *"❌ 不注册，无报错，c.Entries()为空 -
cron.ParseStandard("*/5 * * * * *")❌ 直接 panic：字段数超限 - 若需支持
?或#，必须用cron.ParseQuartz，不能混用
如何避免 AddFunc 静默失败和调度器停摆
AddFunc 内部解析失败只打日志、不返回 error，任务彻底丢失；而任一 job panic 会导致整个调度 goroutine 退出，后续所有任务永久停止。
- 从配置读取表达式后，**必须提前校验**：
cron.ParseStandard(expr)或cron.ParseQuartz(expr)，检查 error - 加
cron.WithChain(cron.Recover(cron.DefaultLogger))，自动包裹每个 job 的 defer/recover - 别裸写
func() { panic("oops") }，即使加了 Recover，panic 仍会记日志，需监控日志确认异常 -
c.Start()后，main 函数必须阻塞（如signal.Notify），否则进程退出，goroutine 被强制终止
时区设置为什么总在北京时间 8 点触发 0 点任务
因为 cron.New() 默认用 time.UTC 解析，写 “0 0 * * *” 实际是 UTC 零点，即北京时间上午 8 点。容器环境还可能因缺失 /etc/localtime 导致 time.Local 加载失败 panic。
- 生产环境推荐显式指定：
cron.New(cron.WithLocation(time.UTC)) - 本地调试可用：
cron.New(cron.WithLocation(time.Local))，但需确保容器已安装 tzdata 并设ENV TZ=Asia/Shanghai - 验证方式：
c.Entry().Schedule.Next(time.Now()).Hour()，看是否符合预期小时值 - 别用
time.LoadLocation("Asia/Shanghai")—— 容器里常找不到时区数据，time.Local更健壮（依赖系统配置）
真正难的不是解析字符串，而是 Cron 的语义本身：它不补偿停机期间的错过触发，不处理任务重入，也不校验“2 月 30 日”这类逻辑无效表达式——这些都得靠测试覆盖或运行时判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
