必须用 cron.ParseStandard 或 cron.ParseQuartz 主动解析表达式，因 AddFunc 解析失败仅输出 warning 日志、不报错不 panic，导致任务静默丢失；二者字段数不同（Standard 为5段、Quartz 为6段），需严格匹配风格，且对空格、字段值等格式极其敏感。
必须用 cron.ParseStandard 或 cron.ParseQuartz 主动解析表达式，不能依赖 AddFunc 的静默行为——后者解析失败只打 warning 日志，任务直接消失，你根本不知道哪条没注册上。
为什么 AddFunc 解析失败却不报错
AddFunc 内部调用解析器失败时，仅通过默认 logger 输出 warning（如 cron: failed to parse spec "0 0 * *": expected 5 fields, found 4），不返回 error，也不 panic。这意味着：
- 从配置文件或数据库读取的表达式若格式错误，程序照常启动
-
c.Entries()返回空 slice，任务彻底“隐身” - 没有主动校验就上线，等于把定时逻辑交给运气
cron.ParseStandard vs cron.ParseQuartz 怎么选
二者字段数、语义和特殊字符完全不同，混用必失败：
-
cron.ParseStandard("0 0 * * *")→ 合法，5 段（分、时、日、月、周），不含秒 -
cron.ParseStandard("*/5 * * * * *")→ 报错：expected 5 fields, found 6 -
cron.ParseQuartz("0 */2 * * * ?")→ 合法，6 段（秒、分、时、日、月、周），支持?和# -
cron.ParseQuartz("0 0 * * *")→ 报错：expected at least 6 fields
日常开发中：
立即学习“go语言免费学习笔记（深入）”；
- 用 Unix 风格（如
"0 */2 * * *"）→ 选cron.ParseStandard - 用 Spring/Quartz 风格（如
"0 0 0 * * ?"）→ 选cron.ParseQuartz - 启用了
cron.WithSeconds()的cron.New()实例，底层实际使用 Quartz 风格 parser，但表达式仍需严格 6 段（如"*/5 * * * * *"），不能混用?
空格、大小写和字段值这些细节真会炸
解析器对格式极其敏感，常见踩坑点：
- 多余空格：
"0 0 * * *"（两个空格）→ 解析失败，别指望 trim - 周字段写
"7"：cron/v3只认0–6（0和7都表示周日，但7被拒绝） - 大小写混合：
"MON,WED"和"mon,wed"都行，但"Mon,Wed"也接受，不区分 - 字段数硬匹配：启用
cron.WithSeconds()后，所有表达式必须是 6 段；否则哪怕只少一段，就静默丢弃
验证是否生效的最快方式
别等上线才发现任务没跑，加一行调试输出就能确认：
entry, _ := c.AddFunc("*/5 * * * * *", func() {})
fmt.Println(c.Entry(entry).Schedule)如果输出是 <nil>，说明表达式解析失败，entry 是无效 ID —— 这时候回头检查 ParseStandard 或 ParseQuartz 的 error 才来得及。
真正容易被忽略的是：即使你用了 cron.WithSeconds()，也得确保所有表达式都严格 6 段，且不含 ? 以外的非法字符；而一旦从配置中心动态加载表达式，空格、换行、BOM 头这些看不见的字符，比语法错误更难排查。
