因为嵌入式或轻量环境依赖过重，需手写仅支持5段标准字段的精简解析器，安全处理、1-3、2,4,6及/15等语法，正确实现day-of-month与day-of-week的“或”逻辑，并规避std::stoi崩溃与时区陷阱。
为什么不能直接用 cron 库而要自己写解析器
因为嵌入式环境或轻量级服务里，libcrontab 或 Boost.Chrono 依赖太重，编译不过、内存超限、或者只需要匹配「每5分钟」这种简单规则——这时候手写一个只处理 5 段标准字段（分 时 日 月 周）的解析器，反而更可控、更易调试。
关键不是“完整实现 RFC 869”，而是快速判断 "*/5 * * * *" 是否匹配当前时间。别一上来就设计 AST 或支持 @reboot 这种扩展语法，先跑通基础字段解析和匹配逻辑。
parse_cron_field 怎么安全处理 *、1-3、2,4,6
每个字段（比如分钟）都要单独解析，返回一个 std::vector<int> 表示所有合法取值。难点不在语法分析，而在边界检查和重复去重。
-
*→ 展开为对应范围全部整数（分钟是0-59，小时是0-23，不能硬编码成 0–59 全局用） -
1-3→ 需校验左 ≤ 右，且都在合法范围内；5-1是非法的，应报错或跳过 -
2,4,6→ 逗号分隔后逐个stoi，但要注意空字符串、非数字（如"2,,4"）、超界值（如"60"在分钟字段） - 组合如
*/15或1-5/2要识别斜杠，先解析基础段再按步长取模生成结果，避免生成{1,3,5}时漏掉1（起始点必须包含）
时间匹配逻辑里最容易忽略的 day-of-month 和 day-of-week 冲突
Cron 规范说：两个字段「或」关系，即满足任一即触发。但很多人误写成「与」——比如 "0 0 1,15 * 1"（每月 1 日、15 日 *且* 周一），实际意思是「1 日或 15 日」或「周一」。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
- 先分别解析
day-of-month和day-of-week得到两个集合 - 若两者都非空，匹配条件是：
current_day ∈ month_days || current_weekday ∈ week_days - 特别注意：有些 Cron 实现把
0和7都当作周日，而 C++std::chrono::weekday返回的是0=Sunday，保持一致即可，不用转成 1–7 - 不要提前 return false —— 必须两个字段都检查完再综合判断
如何避免 std::stoi 崩溃和时区陷阱
std::stoi 遇到空字符串或纯空白会抛 std::invalid_argument，而 Cron 字段可能带空格（如 "1 , 2 , 3"）。别裸用，先 trim 再判断长度。
时区问题更隐蔽：系统时间获取用 std::chrono::system_clock::now()，它返回的是 UTC 时间点，但 std::chrono::floor<std::chrono::hours> 后转本地日历需显式转换。如果业务要求「按服务器本地时间执行」，必须用 std::chrono::current_zone()（C++20）或 std::time_t + localtime_r（C++17 及以前）。
示例片段：
auto now = std::chrono::system_clock::now();
auto local_t = std::chrono::zoned_time{std::chrono::current_zone(), now};
auto day = std::chrono::year_month_day{local_t.get_local_time()}.day().operator int();没做这一步，0 0 * * * 就可能在 UTC 凌晨触发，而不是你期望的本地凌晨。
