应将日期归一化为 std::chrono::system_clock::time_point 再比较，避免直接比较年月日结构体导致闰年、月份天数、时区等逻辑错误。
用 std::chrono 比较日期需要先转成时间点
直接比较年月日结构体（比如自定义的 Date）容易出错，因为闰年、月份天数不一致、时区等逻辑要自己处理。C++ 标准库推荐的方式是把日期归一化为 std::chrono::system_clock::time_point，再用 、<code> 等操作符判断范围。
关键前提是：必须把年/月/日转换为系统时钟能理解的绝对时间点。最稳妥的是用 std::chrono::year_month_day（C++20）配合 sys_days：
using namespace std::chrono;
year_month_day ymd{year{2023}, month{5}, day{15}};
sys_days tp = ymd; // 自动转成 time_point，精度为天
注意：sys_days 本质是 time_point，底层是自纪元以来的天数，不带时分秒，适合纯日期比较。
手动构造 sys_days 时月份和日期容易越界
C++20 的 year_month_day 构造函数不会自动归一化输入值。如果传入 month{13} 或 day{32}，它会保留非法值，后续转 sys_days 时行为未定义（常见表现是程序崩溃或返回错误时间点）。
立即学习“C++免费学习笔记（深入）”；
安全做法是先用 year_month_day{year, month, day}.ok() 校验有效性：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
year_month_day{year{2023}, month{13}, day{1}}.ok()返回false -
year_month_day{year{2023}, month{2}, day{29}}.ok()在非闰年也返回false - 只有校验通过后，才调用
sys_days转换
判断是否在范围内：用 和 <code>，别用 <code> 和 <code>
日期范围通常是“包含起止”的，比如“2023-05-01 到 2023-05-31”。如果用 比较终点，会漏掉最后一天：
sys_days start = year_month_day{year{2023}, month{5}, day{1}};
sys_days end = year_month_day{year{2023}, month{5}, day{31}};
sys_days target = year_month_day{year{2023}, month{5}, day{31}};
// ❌ 错误：target < end 为 false，导致 5 月 31 日被排除
bool in_range = (target >= start) && (target < end);
// ✅ 正确：用 <= 包含终点
bool in_range = (target >= start) && (target <= end);
另外注意：sys_days 是离散类型，相邻两天差值为 1 天，不存在“中间时刻”，所以 是自然且安全的选择。
兼容 C++17 或需支持历史日期时慎用 sys_days
sys_days 基于 system_clock，其纪元是 1970-01-01，部分标准库实现对早于该日期的 sys_days 支持不完整（例如 libc++ 在负天数时可能溢出）。若业务需处理 1900 年前的日期，不要依赖 sys_days。
替代方案是手写比较逻辑（仅限年月日）：
struct Date {
int y, m, d;
bool operator<=(const Date& rhs) const {
if (y != rhs.y) return y < rhs.y;
if (m != rhs.m) return m < rhs.m;
return d <= rhs.d;
}
};
这种写法简单可控，但需自行确保 y/m/d 合法（比如 m 在 1–12），否则比较结果无意义。
真正麻烦的不是怎么写判断，而是怎么定义“合法日期”——闰年规则、大小月、儒略历/格里高利历切换点，这些边界一旦涉及历史数据，就很难靠几个 if 覆盖全。
