std::localtime和std::gmtime非线程安全，因共享静态缓冲区；多线程应使用localtime_r（POSIX）或localtime_s（Windows），注意参数顺序相反；tm_isdst为-1需手动处理；chrono转本地时间须经to_time_t再调用localtime_r/s。
std::localtime 和 std::gmtime 都会修改静态内部缓冲区
直接调用 std::localtime(×tamp) 或 std::gmtime(×tamp) 返回的是指向静态 std::tm 对象的指针，多次调用会互相覆盖。多线程下尤其危险——哪怕你只读不改，两个线程同时调用，拿到的 std::tm* 可能指向同一块内存，内容已变。
实操建议：
- 单线程且只需一次转换：可直接用，但别保存指针，立刻拷贝内容
- 多线程或需多次转换：必须用线程安全版本
std::localtime_r（Linux/macOS）或std::localtime_s（Windows） - 跨平台代码建议封装一层，避免条件编译污染业务逻辑
std::localtime_r 与 std::localtime_s 的参数顺序相反
这是最容易写错的地方：Linux/macOS 的 std::localtime_r 是 (const time_t*, struct tm*)，而 Windows 的 std::localtime_s 是 (struct tm*, const time_t*)。传反了不会编译报错，但结果是未定义行为（比如 tm_year 变成负数、tm_mday 为 0）。
示例对比：
立即学习“C++免费学习笔记（深入）”；
// Linux/macOS struct tm buf; std::localtime_r(&ts, &buf); // Windows struct tm buf; std::localtime_s(&buf, &ts);
常见错误现象：std::tm.tm_year 返回 -1900、tm_mon 为随机大数、整个结构体部分字段为 0——基本就是参数顺序错了。
time_t 到 std::tm 转换后，tm_isdst 可能为 -1
std::tm.tm_isdst 表示是否启用夏令时，标准规定：-1 表示“未知”，0 表示否，>0 表示是。但 std::localtime_r/s 不会自动推断夏令时状态，尤其在时间边界（如 DST 切换日）或系统时区数据陈旧时，它可能留 -1。
使用场景：
- 仅做格式化输出（如
std::strftime）：通常无影响，该函数内部会按需补全 - 做时间计算（如加减小时、判断是否 DST）：必须显式处理
tm_isdst == -1，否则逻辑可能出错 - 若需确定值，可调用
std::mktime(&tm)回转再读取（它会修正tm_isdst）
std::chrono::system_clock::to_time_t 不能直接用于 local 转换
有人想用 std::chrono 时间点转 time_t 再转 std::tm，但要注意：std::chrono::system_clock::to_time_t 返回的是 UTC 时间戳，不是本地时间。如果直接喂给 std::localtime_r，结果是“把 UTC 时间当成本地时间解析”，相当于多套了一层时区偏移。
正确做法：
- 若原始是
std::chrono::system_clock::time_point，先转time_t，再用localtime_r/s - 若需精确控制时区（如非系统默认），不要依赖
localtime系列，改用date::zoned_time（C++20<chrono>扩展）或第三方库如 Howard Hinnant’s date - Windows 上若程序启动后系统时区变更，
localtime缓存可能未刷新，tm_gmtoff字段（非标准）不可靠
复杂点在于：time_t 本身不携带时区信息，所有本地转换都依赖当前进程的 TZ 环境变量或系统设置——这点容易被忽略，尤其在容器或服务部署中。
