std::get_time适用于固定格式日期解析，但需手动校验逻辑合法性；非标准格式推荐正则提取；跨平台避免strptime；提取后必须验证年月日有效性及闰年等规则。
用 std::get_time 解析标准格式日期字符串
如果输入是类似 "2023-12-25" 或 "25/12/2023" 这种固定分隔符、可预测顺序的字符串，std::get_time 是最轻量且安全的选择。它依赖 std::tm 结构，只解析不校验逻辑合法性（比如不会报错 "2023-02-30"），所以后续需自行验证。
- 格式字符串必须与输入严格匹配：
"%Y-%m-%d"对应"2023-12-25"，"%d/%m/%Y"对应"25/12/2023" -
std::get_time会跳过前后空白，但遇到第一个不匹配字符就停止，不会抛异常，需检查流状态：if (ss.fail()) - 年份字段用
%Y（4位）比%y（2位）更可靠，避免 20 → 1920 或 2020 的歧义
处理非标准或模糊格式时改用正则提取
当字符串混杂文字（如 "订单创建于2023年12月25日"）或分隔符不统一（"2023.12.25"、"2023_12_25"），正则更灵活。C++11 起的 std::regex 支持基本需求，但注意其性能开销和部分编译器（如旧版 libstdc++）对 Unicode 不友好。
- 推荐模式：
R"((\d{4})[-._/年]\s*(\d{1,2})[-._/月]\s*(\d{1,2})[日]?)+"，捕获三组数字 - 提取后需手动转换为
int，并验证月份（1–12）、日期（1–31）范围，否则可能得到year=2023, month=0, day=0 - 避免用
.*(\d{4}).*(\d{1,2}).*(\d{1,2}).*—— 贪婪匹配易跨字段捕获，比如"2023-13-01"可能错提成2023,13,01
警惕 strptime 在 Windows 上不可用
Linux/macOS 下常用 strptime 替代 std::get_time，但它不是 C++ 标准函数，Windows 默认 CRT 不提供。若项目需跨平台，不要直接调用 strptime，否则链接失败报 LNK2019: unresolved external symbol strptime。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 跨平台方案：用
std::get_time+ 自定义 locale（如std::locale("zh_CN.UTF-8")处理中文“年月日”） - 或封装条件编译：
#ifdef _WIN32分支改用sscanf拆分，例如sscanf(buf, "%d年%d月%d日", &y, &m, &d) - 注意
sscanf不检查溢出，"99999年1月1日"会导致y溢出，建议配合std::from_chars验证
提取后务必做语义校验
无论用哪种方式拿到三个整数，都不代表日期合法。C++ 标准库不提供轻量级日期校验，得自己写逻辑或引入 <chrono> 构造再捕获异常（但 std::chrono::year_month_day 构造失败会抛 std::runtime_error，且 C++20 才支持）。
立即学习“C++免费学习笔记（深入）”；
- 基础校验项：年份是否在合理范围（如 1900–2100），月份 1–12，日期是否超过当月最大天数（需考虑闰年）
- 简单闰年判断：
(y % 4 == 0 && y % 100 != 0) || (y % 400 == 0) - 别忽略 30 天 vs 31 天月份差异，2 月天数最易出错 —— 很多业务系统因这里漏判导致定时任务错一天
真正麻烦的不是提取数字，而是确认这三个数字合起来是不是一个真实存在的日期。这个校验步骤常被跳过，结果下游用错日期触发数据错乱，比解析失败更难排查。
