应优先使用 cron.ParseStandard 或 cron.ParseQuartz 主动解析表达式并校验 error，避免 AddFunc 因静默 warning 导致任务丢失；二者字段数与语义不同，需严格匹配风格。
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，任务彻底“隐身”
- 没有主动校验就上线，等于把定时逻辑交给运气
必须在调用 AddFunc 前，用 cron.ParseStandard(expr) 或 cron.ParseQuartz(expr) 主动解析并检查 error。例如：
if _, err := cron.ParseStandard("0 0 * * *"); err != nil {
log.Fatal("invalid cron spec:", err)
}
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
日常开发中：
- 用 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.Next(time.Now()))
如果 panic 或返回零时间，说明表达式根本没过解析关。
预定义描述符（如 @every）不是万能的
@every 10s、@hourly 这类描述符走的是独立字符串前缀判断逻辑，绕过字段解析，所以不会因段数问题失败。但它有硬限制：
- @every 后必须跟 time.ParseDuration 能识别的字符串，如 "30s"、"2m"，不能是 "30 seconds"
- @hourly 等价于 "0 * * * *"（v3 下需配合 cron.WithSeconds() 才等效为 "0 0 * * * *"）
- 它们不支持动态变量或拼接，纯字面量匹配
关键提醒：描述符解析失败会直接返回 error，不像 AddFunc 那样静默吞掉——所以如果你用 cron.ParseStandard("@every 10s")，它一定报错，因为这不是标准格式。
复杂点在于：表达式语法合法 ≠ 时间逻辑合理。比如 "0 30 31 <em> </em>" 在 2 月永远不触发，调度器不会提前告诉你。这类问题只能靠测试用例覆盖边界日期，或在任务函数里加运行时校验。
