必须先将std::chrono::system_clock::now()转为std::time_t才能用std::strftime格式化，因后者仅接受C风格时间戳；to_time_t()会截断毫秒，高精度需手动提取duration；%F和%T便捷但兼容性差，多线程应避免std::localtime而用localtime_r/s；C++20 std::format虽简洁但跨平台支持不稳。
用 std::chrono 获取系统时间后，必须先转成 std::time_t 才能格式化
因为 std::chrono::system_clock::now() 返回的是一个高精度时间点（time_point），不是 C 风格的秒级时间戳。直接拿它去调 std::strftime 会编译失败——类型不匹配是初学者最常卡住的地方。
正确路径是：
system_clock::now() → system_clock::to_time_t() → std::localtime 或 std::gmtime → std::strftime
注意：to_time_t() 截断了毫秒/纳秒部分，只保留到秒；如果需要更高精度，得手动拆解 time_point 的 duration 值。
std::strftime 的格式字符串里，%F 和 %T 最省事但兼容性有限
%F 等价于 %Y-%m-%d，%T 等价于 %H:%M:%S，组合起来就是 "%F %T"，输出类似 "2024-06-12 15:38:22"。但它在 Windows MinGW 或旧版 libc 上可能不被支持。
更稳妥的写法是显式拼接：
立即学习“C++免费学习笔记（深入）”；
char buf[64]; auto t = std::time(nullptr); auto tm = *std::localtime(&t); std::strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M:%S", &tm);
常见坑：
-
buf太小会导致截断（%Y-%m-%d %H:%M:%S至少要 20 字节） -
std::localtime返回的是静态缓冲区指针，多线程下不安全；并发场景要用std::localtime_r（POSIX）或std::localtime_s（Windows） - 忘记初始化
tm结构体（比如直接用未赋值的std::tm{}传给strftime）会导致未定义行为
想保留毫秒？得手动从 time_point 提取 duration
std::chrono::system_clock::now() 的底层 duration 类型通常是 nanoseconds 或 microseconds，但标准不保证。不能假设 .count() 就是毫秒数。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
安全做法是转换到目标精度再取余：
auto now = std::chrono::system_clock::now(); auto ms = std::chrono::time_point_cast<std::chrono::milliseconds>(now); auto s = std::chrono::time_point_cast<std::chrono::seconds>(now); auto msec = (ms - s).count(); // 毫秒部分，范围 0–999
然后把 s 转成 time_t 格式化日期时间，再拼上 msec：
sprintf(buf, "%s.%03ld", formatted_time_c_str, msec);
注意：std::strftime 不支持毫秒占位符，硬加 %3N 之类会静默失败。
C++20 的 <format> 是未来方向，但目前 MSVC/GCC 支持还不稳
std::format 可以直接处理 std::chrono::time_point，写法简洁：
auto now = std::chrono::system_clock::now();
std::string s = std::format("{:%Y-%m-%d %H:%M:%S}", now); // C++20但现实是：
- MSVC 19.3x 开始支持，但需开启
/std:c++20且链接时可能报错 - GCC 13 默认不启用
std::format的 chrono 特化，得加编译选项或等 14 - Clang 对
<format>的 chrono 支持更滞后
生产环境别贸然用，尤其跨平台项目。宁可多写几行 strftime + 手动拼毫秒，也比 runtime 崩溃强。
真正麻烦的从来不是“怎么写”，而是“哪个平台、哪个标准库版本、是否多线程”这些上下文——漏掉任何一个，都可能让同一段代码在 CI 和本地表现不同。
