std::format是C++20首选占位符方案，语法类似Python str.format()，支持位置/命名占位符和格式说明符，类型安全；需显式传参，编译器检查数量与类型；MSVC 19.30+、GCC 13+、Clang 15+完整支持，GCC 13默认需链接-lstdc++_libfmt；旧标准可用fmt库替代，性能更优且API一致。
std::format 是 C++20 最直接的占位符方案
如果你用的是 C++20 或更新标准，std::format 就是首选——它语法接近 Python 的 str.format()，支持位置占位符、命名占位符和格式说明符，且类型安全。
常见错误是误以为它像 printf 那样接受可变参数包：实际必须显式传入每个参数，编译器会检查数量和类型匹配。
-
std::format("Hello, {}!", "World")→"Hello, World!" -
std::format("Pi ≈ {:.2f}", 3.14159)→"Pi ≈ 3.14" -
std::format("{name} is {age} years old", std::make_format_args("Alice", 30))不推荐手写std::make_format_args；命名占位符需配合std::format_named（C++23）或改用位置索引更稳妥
注意：MSVC 19.30+、GCC 13+、Clang 15+ 才完整支持 std::format；GCC 13 默认仍需链接 -lstdc++_libfmt（取决于构建配置），否则链接时报 undefined reference to std::format。
兼容 C++11/14/17 的 fallback：fmt 库最实用
项目不能升级到 C++20？直接用第三方 fmt 库（fmtlib）——它正是 std::format 的参考实现，API 几乎一致，且稳定支持旧标准。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑是头文件引入方式：不推荐全量 #include <fmt/format.h>（体积大），按需用 #include <fmt/core.h>（基础占位符）或 #include <fmt/ranges.h>（容器格式化）。
- 安装后：
fmt::format("Value: {:x}", 255)→"Value: ff" - 支持编译期检查：启用
FMT_COMPILE_STRING后，错写"{0} {2}"（跳过索引 1）会在编译时报错 - 性能比
std::ostringstream高 3–5 倍，尤其在拼接多字段日志时明显
别把 fmt::print 当作唯一入口——它直接输出到 stdout，调试时方便，但生产代码中建议统一用 fmt::format 返回 std::string，便于后续处理或缓存。
避免用 std::ostringstream 拼接占位符字符串
有人试图用 std::ostringstream + 多次 << 模拟占位符，比如写个函数把 "{}" 替换成值。这属于“自己造轮子还漏气”：既没类型安全，也不支持对齐、进制、精度等格式控制，而且替换逻辑极易出错（如嵌套大括号、转义处理）。
典型翻车场景：
- 原始字符串含
"path/to/{file}.log"，正则替换"{file}"时误匹配"{file}.log"中的"{file" - 传入
double值但未设置std::fixed和precision，输出科学计数法而非预期小数位 - 多线程环境下共享同一个
std::ostringstream对象，导致输出乱序或截断
真要手写替换，至少用 std::string::find + std::string::replace 做单次精确匹配，并限制替换次数（防止无限循环），但依然不如 fmt 省心。
命名占位符在 C++23 前基本不可靠
C++20 的 std::format 不支持命名参数（如 {name}），C++23 才加入 std::format_named。目前强行模拟命名占位符，常见做法是预定义 std::map<std::string, std::string> 再做字符串替换——但这彻底丢失类型信息，所有值都得先转成字符串，无法做运行时格式化（比如临时决定某数字显示为十六进制）。
如果业务强依赖命名占位符（如模板引擎场景），建议：
- 用
fmt库的fmt::dynamic_format_arg_store构建运行时参数集，再调用fmt::vformat - 或切换到专用模板库（如
inja），而非硬塞进格式化函数
别为了“看起来像 Python”牺牲类型安全和性能——位置占位符加清晰的参数顺序注释，通常比模糊的命名更易维护。
