最可靠的方式是用 std::chrono::year_month_day 提取月份后按气象季规则判断：3–5月春、6–8月夏、9–11月秋、12–2月冬，注意跨年逻辑和 month() 返回值为 1–12，避免 tm_mon 未加1导致的偏移错误。
用 std::chrono 提取月份再判断季节最可靠
没有标准库函数能直接返回“春季”“冬季”这种字符串，必须自己根据月份映射。C++20 起 std::chrono 提供了足够精确的本地时间获取能力，比旧式 localtime + time 更安全、更易读。
关键点在于：季节划分依赖于你采用的标准（天文季 vs 气象季），国内常用气象季（3–5月为春，6–8月为夏，9–11月为秋，12–2月为冬），且必须考虑跨年逻辑（12月属于冬季，但要和1、2月归为同一季）。
- 用
std::chrono::system_clock::now()获取当前时间点 - 转成
std::chrono::year_month_day提取month()值（范围是1–12） - 对
month()做模运算或条件分支判断归属季节，避免硬写if (m == 12 || m == 1 || m == 2)这类易错逻辑
避免用 tm_mon 直接加1后判断的坑
std::tm::tm_mon 返回的是 0–11，不是 1–12 —— 这是 C 风格时间 API 最常踩的坑。如果没加1就直接比较，会导致所有季节偏移一个月（比如把3月当成2月，误判为冬季）。
即使你用 std::localtime，也得手动加1才能得到正确月份：
auto now = std::time(nullptr); auto tm = *std::localtime(&now); int month = tm.tm_mon + 1; // 必须加1！
更糟的是，std::localtime 返回的是静态缓冲区指针，多线程下不安全；而 std::gmtime 返回 UTC 时间，未考虑时区偏移——这两点在服务端或跨时区场景下会出问题。
封装成函数时，季节字符串建议用 std::string_view 返回
季节名是固定字面量，没必要每次构造 std::string。用 std::string_view 零拷贝返回，既高效又避免生命周期问题。
示例实现（气象季）：
std::string_view get_season() {
auto ymd = std::chrono::floor<:chrono::days>(
std::chrono::system_clock::now());
auto [y, m, d] = std::chrono::year_month_day{ymd};
int month = static_cast<int>(m); // m 是 std::chrono::month，需转 int
if (month >= 3 && month = 6 && month = 9 && month
<p>注意：<code>std::chrono::year_month_day</code> 构造需要先用 <code>floor<days></days></code> 截断到日精度，否则可能因纳秒部分导致异常行为。</p>
<h3>Windows 下若用 <code>GetLocalTime</code>，别忽略 <code>wMonth</code> 已是 1–12</h3>
<p>Win32 API 的 <code>SYSTEMTIME::wMonth</code> 直接返回 1–12，不需要像 <code>tm_mon</code> 那样加1。但它的时区处理依赖系统设置，且无法指定时区，移植性差。</p>
<p>如果你已深度绑定 Windows 平台，且确定无需跨平台，可以这样用：</p>
<pre class="brush:php;toolbar:false;">SYSTEMTIME st;
GetLocalTime(&st);
int month = st.wMonth; // ✅ 已是 1–12，直接用
不过要注意：GetLocalTime 不受 SetThreadLocale 影响，只反映系统时区设置；若程序运行在容器或远程桌面中，时区可能被覆盖，结果不可靠。
跨年季节边界（比如12月）最容易被忽略——它不属于“年底”，而是冬季的起始，逻辑上必须和1、2月统一处理，而不是单独写一个 if (month == 12) 分支。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
