<p>Linux/macOS 推荐 localtime_r，Windows 推荐 localtime_s；两者参数顺序相反，localtime_r(&ts, &tm) 为 time_t 在前，localtime_s(&tm, &ts) 为 struct tm 在前，跨平台需条件编译封装。</p>
time_t 转 struct tm 用 localtime_r 还是 localtime_s？
直接用 localtime 是线程不安全的，Linux/macOS 推荐 localtime_r，Windows 推荐 localtime_s——两者参数顺序相反，容易传错导致崩溃或乱码。
关键区别：
-
localtime_r(&ts, &tm)：time_t*在前，struct tm*在后（POSIX） -
localtime_s(&tm, &ts)：struct tm*在前，time_t*在后（MSVC） - 两个函数都要求
tm内存已分配，不能传未初始化指针或栈上野地址
跨平台写法建议封装一层：
#ifdef _WIN32
localtime_s(&tm, &ts);
#else
localtime_r(&ts, &tm);
#endif
格式化输出用 strftime 时日期字段对不上？
strftime 的格式符和 struct tm 字段是强绑定的，常见错位：比如 %Y 对应 tm.tm_year，但后者是「距1900年的年数」，不是实际年份；而 %m 对应 tm.tm_mon，却是 0–11（不是 1–12）。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑：
- 误以为
tm.tm_year == 2024→ 实际要加 1900 才能打印正确年份，但strftime("%Y")已自动处理，无需手动加 - 用
%d打印日没问题，但若想补零成两位（如 "05"），必须用%02d或依赖strftime默认行为（它默认补零） - Windows 下
%F（等价于%Y-%m-%d）可能不支持，建议拆成%Y-%m-%d以保兼容
示例（安全获取 "2024-06-12"）：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
char buf[32]; strftime(buf, sizeof(buf), "%Y-%m-%d", &tm);
时间戳是毫秒级，time_t 直接赋值会出错？
time_t 通常是秒级整数（POSIX 要求），如果原始时间戳是毫秒（比如 JavaScript Date.now() 或某些 API 返回），直接赋给 time_t 会导致时间快 1000 倍。
必须先除以 1000：
- 确认输入单位：检查文档或打印原始值（如
1718179200000是毫秒，÷1000 =1718179200才是标准 Unix 时间戳） - 整除即可，毫秒部分丢弃（
ts_ms / 1000），除非你需要微秒级精度并改用std::chrono - 别用浮点转换再转整，易因精度丢失导致秒数偏差
错误示范：time_t t = 1718179200000; → 实际解析为公元 56429 年
C++20 std::chrono 能否更可靠？
可以，但要注意：C++20 的 std::format 和 std::chrono::sys_time 尚未在所有编译器完全落地（如 GCC 13 默认仍需 -std=c++2b，MSVC 2022 v17.5+ 支持较好）。
若可用，推荐路径：
- 用
std::chrono::system_clock::from_time_t(ts)转为sys_time - 再用
std::format("{:%Y-%m-%d}", time_point)格式化 - 优势是类型安全、无缓冲区溢出风险、线程安全；劣势是目前还不能替代
strftime的全部格式符（如中文星期名）
当前更务实的选择仍是 localtime_r/localtime_s + strftime，尤其在嵌入式或旧系统环境。
真正麻烦的从来不是“怎么转”，而是没确认清楚时间戳单位、时区上下文、以及目标平台对 POSIX/Windows 函数的细微差异。
