现代C++推荐用std::chrono获取Unix时间戳：秒级用duration_cast<seconds>，毫秒级用duration_cast<milliseconds>；格式化需线程安全的localtime_r/gmtime_r及strftime，避免ctime等不安全函数。
用 std::chrono 获取当前时间戳（秒/毫秒级）
现代 C++ 推荐用 std::chrono，它类型安全、无时区歧义，且不依赖 C 风格的全局状态。直接获取 Unix 时间戳（自 1970-01-01 00:00:00 UTC 起的秒数或毫秒数）最稳妥：
-
std::chrono::system_clock::now().time_since_epoch().count()返回的是纳秒级计数，需除以对应倍数才能转成秒/毫秒 - 更推荐用
std::chrono::duration_cast显式转换，避免整数溢出或精度丢失：比如std::chrono::duration_cast<:chrono::seconds>(std::chrono::system_clock::now().time_since_epoch()).count()</:chrono::seconds> - 注意：
system_clock不保证是 UTC（C++20 前），但实践中主流平台（Linux/macOS/MSVC）都按 UTC 实现；若需强保证，应搭配std::chrono::utc_clock（C++20）
用 std::put_time 格式化为本地时区日期字符串
拿到时间戳后想转成 "2024-05-20 14:30:45" 这类可读格式，得先转成 std::tm，再用 std::put_time 输出。关键在「时区」——std::localtime 是线程不安全的，std::localtime_r（POSIX）或 std::localtime_s（Windows）才是安全选择：
- 先用
std::chrono::system_clock::to_time_t把时间点转成time_t - 再调用线程安全版本：比如 Linux 上用
std::localtime_r(&t, &tm_buf)，Windows 上用std::localtime_s(&tm_buf, &t) -
std::put_time只接受const std::tm*，不支持直接传std::chrono::time_point - 常见错误：直接用
std::localtime在多线程里导致时间错乱；或忘了初始化tm_buf结构体（某些平台会残留脏数据）
跨平台处理 UTC 时间格式（避免本地时区干扰）
如果日志、协议或 API 要求严格 UTC 格式（如 ISO 8601），就不能依赖 localtime 系列函数。C++20 引入了 std::format 和 std::chrono::zoned_time，但老标准下只能靠 std::gmtime_r/std::gmtime_s：
- 用
std::gmtime_r(&t, &tm_buf)（Linux/macOS）或std::gmtime_s(&tm_buf, &t)（Windows）获取 UTC 的tm - 格式化时用
%Y-%m-%d %H:%M:%S即可，不用改逻辑 - 注意：
std::gmtime同样线程不安全，必须用带_r或_s后缀的变体 - Windows 下若未定义
_CRT_SECURE_NO_WARNINGS，std::gmtime_s可能触发编译警告，需加#pragma warning(suppress: 4996)或配置项目属性
旧代码踩坑：别用 time() + ctime() 直接拼字符串
ctime(&t) 返回的是带换行符的静态字符串（如 "Mon May 20 14:30:45 2024\n"），看似方便，实则暗藏三处硬伤：
立即学习“C++免费学习笔记（深入）”；
- 返回值指向内部静态缓冲区，多次调用会相互覆盖，多线程下必出问题
- 格式固定不可控，无法去掉换行、无法切分年月日、无法适配中文 locale
-
ctime本质调用localtime，受系统时区环境变量（如TZ）影响，部署到不同服务器可能结果突变 - 替代方案：宁可用
std::strftime配合线程安全的localtime_r，哪怕多写两行
真正难的不是“怎么转”，而是想清楚你要的是 UTC 还是本地时间、是否并发安全、是否跨平台一致——这些决定一上来就选错函数，后面全得返工。
