不安全。std::chrono::system_clock::time_point 无法直接提取年月日，需转为日历时间；C++20 的 year_month_day 在旧编译器（如 GCC）中可能不支持。
用 std::chrono 解析年月日再比较是否安全？
不安全。直接用 std::chrono::system_clock::time_point 无法提取年、月、日字段，必须先转成日历时间。C++20 引入了 std::chrono::year_month_day，但若编译器不支持（如 GCC
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 确认编译标准：加
-std=c++20并检查__cpp_lib_chrono宏值 ≥ 201907L - 若不可用 C++20，退回到
std::tm+std::mktime/std::gmtime组合，注意时区和本地化影响 - 避免用
std::chrono::duration_cast按“30 天”粗略判断——闰年、大小月会导致误判
手动提取年月：用 std::tm 时为什么 tm_mon 要加 1？
因为 std::tm::tm_mon 的取值范围是 0–11（0 表示一月），而人类习惯的月份是 1–12。比较同月时若忘记归一化，会导致 1 月 vs 12 月被误判为“不同月”。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 两个日期都转成
std::tm后，直接比tm_year和tm_mon即可，无需加 1 - 注意
std::mktime会修改输入的tm结构体（例如归一化tm_mday），传入前最好复制一份 - 若日期来自字符串（如
"2023-04-15"），用std::get_time解析后，tm_mon已是 0-based，别再减 1
跨时区比较两个 time_t 是否同月，该怎么处理？
不能直接比 tm_mon —— 同一个 time_t 值在不同时区下可能落在不同月份（例如 UTC 时间 2023-03-31 23:00，在 UTC+8 是 2023-04-01 07:00）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 明确业务语义：是“用户本地时间同月”，还是“UTC 时间同月”？前者用
localtime，后者用gmtime - 统一转成 UTC 再比较更可靠，尤其涉及日志、审计等场景
- 避免混用：不要一个用
localtime，另一个用gmtime，否则 12 小时制偏差就足以让结果错乱
C++20 下最简实现：为什么不能只比 y/m 而要构造 year_month？
因为 std::chrono::year_month_day 不可直接比较年月；它携带完整日信息，直接比 ymd1.year() == ymd2.year() && ymd1.month() == ymd2.month() 可行，但不如用 year_month 语义清晰且防错。
实操示例：
auto ymd1 = std::chrono::year_month_day{sys_days{2023y/4/15}};
auto ymd2 = std::chrono::year_month_day{sys_days{2023y/4/30}};
auto ym1 = ymd1.year()/ymd1.month(); // year_month
auto ym2 = ymd2.year()/ymd2.month();
if (ym1 == ym2) { /* same month */ }
注意点：
-
sys_days构造要求输入是year_month_day，不能直接传time_t或字符串 - 若日期可能无效（如 2023-02-30），
year_month_day构造会抛std::runtime_error，需捕获 - 非 C++20 环境下，这套写法连编译都过不了，别抄到旧项目里
真正麻烦的不是怎么写，而是得先确认你的工具链、时区策略、输入来源这三件事有没有对齐。漏掉任意一个，代码跑得再顺，结果也可能错得离谱。
