fmt::format 更值得优先使用，因其默认不抛异常、支持编译期格式检查、实现零开销抽象，且语法接近 Python 的 f"{x}"；而 std::ostringstream 需多次拼接。
fmt::format 为什么比 std::ostringstream 更值得优先用
因为默认不抛异常、支持编译期格式检查、零开销抽象，且语法接近 Python 的 f"{x}"。std::ostringstream 要拼接多次 ，易出错，还容易忘记清空 <code>std::ios_base::failbit 状态。
- 字符串拼接场景下，
fmt::format("name: {}, age: {}", name, age)比手动构造std::ostringstream少写 5–8 行，且无内存泄漏风险 - 编译器能静态检查格式串与参数数量/类型是否匹配（启用
-D__cpp_lib_format和 C++20 支持后） - 不依赖 iostream，可安全用于嵌入式或日志系统中禁用流的环境
C++20 std::format 在 MSVC/GCC/Clang 上的实际兼容性
不是所有“支持 C++20”的编译器都默认开启 std::format——它依赖标准库实现进度，而非单纯语言版本。
- MSVC 19.30+（VS 2022 17.0+）需定义
_HAS_CXX20=1并链接stdc++fs（仅 Windows） - GCC 13 默认启用，但 GCC 12 需加编译选项
-std=c++2b -lstdc++且部分格式（如{:.2f}）行为未完全对齐 - Clang 16 + libc++ 16 可用，但 Clang 15 及更早版本即使加
-std=c++20也报error: no member named 'format' in namespace 'std' - 若项目需跨编译器稳定输出，直接用
fmt::format（v10.0+）比赌std::format更省心
常见格式化错误：日期、宽字符、自定义类型怎么写才不出错
这三个是 fmt 最常翻车的点，不是语法写错，而是隐式转换或缺失特化导致运行时报 format error: unknown format specifier 或静默截断。
- 时间类型必须显式转成字符串或用
fmt::strftime：fmt::format("{:%Y-%m-%d}", std::chrono::system_clock::now())，直接传std::time_t会失败 - 宽字符串（
std::wstring）不能直接进fmt::format，得先转 UTF-8：fmt::format("msg: {}", wstring_convert_utf8(my_wstr))，否则触发编译错误no matching function for call to 'format' - 自定义结构体要支持格式化，必须提供
fmt::formatter<MyType>特化，而不是重载operator<<；漏掉parse()函数会导致invalid format string
性能敏感场景下，fmt::format 和 snprintf 对比的关键取舍
fmt 默认安全，但某些嵌入式或高频日志路径里，snprintf 的栈上缓冲仍比 fmt::format 的堆分配快 1.5–3 倍——前提是格式串固定、参数少、且你能控制缓冲区大小。
立即学习“C++免费学习笔记（深入）”；
- 用
fmt::memory_buffer可避免堆分配：fmt::memory_buffer buf; fmt::format_to(buf, "id={}", id); auto s = to_string(buf); - 若已知最大长度（比如日志行不超过 1024 字节），
snprintf(buf, sizeof(buf), "id=%d", id)零分配、无异常、CPU 指令更少 - 但
snprintf不支持类型安全、不处理宽字符、格式串写错会在运行时静默截断，而 fmt 在编译期就报错 - 真正高频路径（如每秒万级日志）建议封装一层：调试/开发用
fmt::format，发布版切到snprintf分支
fmt 的坑不在语法，而在类型推导边界和标准库实现温差；std::format 看起来是“标准答案”，但落地时得查编译器文档，而不是只看 C++ 版本号。
