最直接的方式是用 std::gmtime（或跨平台可重入版本）转 time_t 为 std::tm，再以 "%Y%m%d%H%M%S" 格式通过 std::ostringstream << std::put_time 输出 UTC 时间字符串；避免使用 std::localtime 防时区干扰。
用 std::put_time 格式化 time_t 为 YYYYMMDDHHMMSS
最直接的方式是转成 std::tm，再用 std::put_time 输出。注意必须用本地时间还是 UTC —— 多数场景要 UTC（比如日志时间戳），但 std::localtime 默认用本地时区，容易出错。
实操建议：
- 用
std::gmtime而非std::localtime，避免时区干扰 -
std::put_time需要std::ostringstream配合，不能直接作用于char* - 格式字符串用
"%Y%m%d%H%M%S"，%Y是 4 位年份，%y是 2 位，别混用
time_t now = std::time(nullptr);
std::tm tm_buf {};
gmtime_r(&now, &tm_buf); // Linux/macOS；Windows 用 _gmtime64_s
std::ostringstream oss;
oss << std::put_time(&tm_buf, "%Y%m%d%H%M%S");
std::string s = oss.str(); // 如 "20240521143205"
gmtime_r 和 _gmtime64_s 的跨平台写法
std::gmtime 在多线程下不安全（返回静态缓冲区），C++11 后推荐用可重入版本，但 Windows 和 POSIX 实现不同。
常见错误现象：std::gmtime 在并发调用时返回乱值，尤其在循环中反复调用时出现时间倒退或全零。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- Linux/macOS：用
gmtime_r(&t, &tm_buf)，tm_buf必须是栈上变量 - Windows：用
_gmtime64_s(&tm_buf, &t)，第一个参数是地址，第二个是time_t* - 封装一层宏或内联函数屏蔽差异，别裸写
std::gmtime
不用 iostream（避免流开销）的 C 风格方案
如果对性能敏感（比如高频日志打点），std::ostringstream + std::put_time 有动态内存分配和 locale 开销，可改用 strftime。
使用场景：嵌入式、高频时间戳生成、避免 STL 流对象构造/析构成本。
实操建议：
- 目标缓冲区至少 15 字节（14 位 +
\0），但建议留 32 字节防扩展 -
strftime返回 0 表示失败（比如缓冲区太小），务必检查 - 仍需先调用
gmtime_r或_gmtime64_s填充tm结构体
char buf[32];
std::tm tm_buf {};
gmtime_r(&now, &tm_buf);
if (strftime(buf, sizeof(buf), "%Y%m%d%H%M%S", &tm_buf) == 0) {
// 处理错误
}
时区偏移导致的 YYYYMMDDHHMMSS 错位问题
很多人用 std::localtime 得到的时间字符串看起来“对”，但一换机器或改系统时区就变——比如服务器在 UTC+8，测试机在 UTC，同一 time_t 会差 8 小时。
性能 / 兼容性影响：时区计算本身开销不大，但结果不可重现，对日志归档、文件名生成、分布式 trace ID 等场景是硬伤。
实操建议：
- 所有服务端时间戳统一用 UTC，不要依赖系统本地时区
- 如果必须显示本地时间，转换逻辑应显式指定时区（如用
std::chrono::zoned_timeC++20） - CI/CD 中验证时间格式输出时，临时设
TZ=UTC环境变量跑测试
真正麻烦的是隐式依赖本地时区的遗留代码，它不会报错，只会在跨环境部署后悄悄错几个小时。
