标准C++中tm_wday字段表示星期几，周日为0、周六为6；需手动转换为周一为1的格式，即(wday == 0 ? 7 : wday)。
用 std::chrono 和 std::localtime 获取星期几（周日为 0 还是周一为 1？）
标准 C++ 没有直接返回“本周第几天”的函数，std::chrono 自 C++20 起才支持日历运算，但多数项目仍用 C 风格时间处理。最稳妥的做法是先获取 std::tm，再读取其 tm_wday 字段——它表示**星期几，周日为 0，周六为 6**。
注意：这和 ISO 8601（周一为 1，周日为 7）或某些业务逻辑（如“本周第 1 天 = 周一”）不一致，必须手动转换。
实操建议：
- 用
std::time(nullptr)获取当前秒级时间戳 - 用
std::localtime转成本地时区的std::tm（注意：该函数非线程安全，多线程需用std::localtime_r） -
tm_wday是只读字段，值范围固定为 0–6
把 tm_wday 转成“周一为第 1 天”的序号
很多场景要求周一作为每周起点（比如排班、报表周期），这时不能直接用 tm_wday，得做偏移映射。
立即学习“C++免费学习笔记（深入）”；
常见错误：写成 (tm_wday == 0 ? 7 : tm_wday) —— 这得到的是 1–7，但“第几天”通常指序数（周一=1，周二=2…周日=7），没问题；但若你想要“距离周一的天数差”（即周一=0），就得用 (tm_wday + 6) % 7。
推荐按需选择：
- 要“本周第 N 天（周一为 1）” →
(tm_wday == 0 ? 7 : tm_wday) - 要“本周第 N 天（周一为 0）” →
(tm_wday + 6) % 7 - 别硬记公式，现场用小表验证：
sun=0→7, mon=1→1, ..., sat=6→6
C++20 std::chrono::year_month_day 怎么用？
C++20 引入了真正的日历类型，可避免 std::tm 的时区陷阱和可变字段语义模糊问题。但要注意：它默认按 UTC 解析，且 weekday() 成员返回的是 std::chrono::weekday 类型，不是整数。
关键步骤：
- 用
std::chrono::system_clock::now()获取当前时间点 - 转成
std::chrono::floor<:chrono::days></:chrono::days>得到当天零点 - 构造
std::chrono::year_month_day，再调.weekday().c_encoding()（返回 0=Sunday, 6=Saturday，和tm_wday一致） - 仍需手动转成“周一为 1”，逻辑同上
示例片段：
auto now = std::chrono::system_clock::now();
auto today = std::chrono::floor<std::chrono::days>(now);
std::chrono::year_month_day ymd{today};
int wday = static_cast<int>(ymd.weekday().c_encoding()); // 0–6
int day_of_week_mon1 = (wday == 0 ? 7 : wday);
跨平台时 localtime 的时区行为差异
Windows 和 Linux 下 std::localtime 都依赖系统时区设置，但初始化方式不同：Linux 通常读 TZ 环境变量或 /etc/localtime，Windows 依赖系统控制面板设置。如果程序部署在容器或 CI 环境中，localtime 可能返回 UTC（因容器未配置时区）。
容易踩的坑：
- 没设
TZ环境变量的 Docker 容器 →localtime返回 UTC 时间，tm_wday对应的是 UTC 星期几，而非你期望的本地星期几 - 用
std::gmtime替代localtime却没意识到这是 UTC → 结果永远比本地慢/快若干小时 - 测试时本地开发机正常，上线后出错 → 先检查容器或服务器的时区配置
临时验证方法：打印 tm.tm_zone（POSIX）或调 _get_tzname（Windows）看是否符合预期。
真正可靠的做法是明确指定时区（如用 ICU 或 date.h 库），但纯标准库下，只能确保运行环境时区已正确设置。
