因为 tm_mon 的取值范围是 0–11（0 表示一月），不是 1–12，直接使用需加 1；C++20 的 year_month_day::month() 直接返回 1–12，更安全简洁。
用 std::localtime 和 tm_mon 获取月份时为什么总是错 1 个月？
因为 tm_mon 的取值范围是 0–11（0 表示一月），不是 1–12。这是 C 标准库沿袭的“零起点”设计，直接返回 tm.tm_mon 就会得到 0–11，必须加 1。
常见错误写法：int month = tm.tm_mon; → 结果是 0 而不是 1（一月）。
正确做法：
- 调用
std::time(nullptr)获取当前时间戳 - 用
std::localtime转成std::tm结构体（注意：线程不安全；多线程请用std::localtime_r或 C++20 的std::chrono::current_zone()） - 取
tm.tm_mon + 1
示例代码：
立即学习“C++免费学习笔记（深入）”；
std::time_t now = std::time(nullptr);
std::tm tm_buf {};
#ifdef _WIN32
localtime_s(&tm_buf, &now); // Windows 安全版本
#else
localtime_r(&now, &tm_buf); // POSIX 线程安全版本
#endif
int month = tm_buf.tm_mon + 1; // ← 关键：+1 才是 1-12
C++20 用 std::chrono 和 std::format 更安全吗？
是的，std::chrono 避免了 std::tm 的可变时区、静态缓冲区和线程安全问题；std::format（C++20）也比 sprintf 类接口更类型安全。
但要注意：标准库对日历计算支持仍有限，std::chrono::year_month_day 是唯一能直接提取“月份为 1–12”的类型，且无需手动加减。
使用条件：
- 编译器需支持 C++20（如 GCC 12+、Clang 14+、MSVC 19.30+）
- 启用
-std=c++20，且确保<chrono>和<format>可用
示例：
auto now = std::chrono::system_clock::now();
auto ymd = std::chrono::year_month_day{std::chrono::floor<std::chrono::days>(now)};
int month = static_cast<int>(ymd.month()); // ← 直接返回 1–12，无需 +1
Windows 下用 GetLocalTime 会不会更简单？
对纯 Win32 项目确实更轻量：不依赖 C 运行时，无静态缓冲区风险，且字段名语义清晰（wMonth 就是 1–12）。
但它是平台专属 API，跨平台代码中应避免直接使用；若已限定 Windows 环境，它比 localtime_s 更少出错。
关键点：
-
SYSTEMTIME.wMonth是 1–12，天然符合需求 - 必须初始化结构体（否则未定义行为），推荐用
{0}或= {}零初始化 - 不涉及时区转换逻辑，就是当前系统设置下的本地时间
示例：
SYSTEMTIME st{};
GetLocalTime(&st);
int month = st.wMonth; // ← 直接可用，不用加减
为什么不能只靠 std::strftime 格式化字符串来“取月份”？
可以格式化，但无法直接获得整数月份值 —— std::strftime 返回的是字符串（比如 "03"），需要额外调用 std::stoi 解析，引入不必要的转换开销和异常风险（如 locale 导致解析失败）。
更隐蔽的问题是：如果只为了取月份，却构造了完整日期字符串（如 "2024-03-15"），性能和内存都不如直接访问 tm_mon 或 year_month_day::month()。
适用场景仅限于：你本来就要生成日期字符串，顺便“顺手”提取月份；否则纯属绕路。
总结：别为了一个整数去走字符串路径，除非你在做日志模板或 UI 显示。
