c++oding="utf-8" ?>
std::format 在日志场景下默认不比 sprintf/ostream 快，常慢 2–5 倍；应仅用于低频日志，高频日志改用 snprintf 或字符串视图拼接，并显式指定 c locale、预格式化、避免多线程直接调用，或选用 fmt::format 等更优替代方案。
std::format 在日志场景下真的比 sprintf/ostream 快吗？
不快——至少默认情况下不是。std::format 的设计目标是类型安全和可扩展性，不是极致吞吐。实测中，对简单格式如 "{} {}"，它常比 snprintf 慢 2–5 倍；只有在复杂格式（含宽字符、本地化、嵌套对齐）且启用编译器优化（-O2 及以上）时，才可能接近或略超 fmt::format（但依然难赢 snprintf）。日志性能瓶颈通常不在格式化本身，而在 I/O 和锁竞争，所以盲目替换 std::format 很可能拖慢整体。
怎样写才能让 std::format 不拖累日志性能？
关键不是“怎么用”，而是“什么时候用、怎么绕开它”。实际可行的策略包括：
- 只对非高频日志（如启动信息、错误上下文）使用
std::format，高频 debug/info 日志改用预分配缓冲 +snprintf或零拷贝字符串视图拼接 - 避免运行时解析格式串：把
"[{}] {}"_format(level, msg)拆成编译期已知的字面量，例如用std::format("{:%Y-%m-%d %H:%M:%S} [{}] {}", std::chrono::system_clock::now(), level, msg)—— 这里时间格式串是常量，编译器可部分优化 - 禁用 locale 相关功能：传入
std::locale::classic()显式指定 C locale，否则std::format可能触发std::use_facet查表，带来不可预测延迟 - 不要在多线程日志入口直接调用
std::format：它内部有小量动态内存申请（尤其含变长参数时），应提前在无锁上下文中完成格式化，再交由日志队列异步写入
替代方案比硬啃 std::format 更有效
C++20 的 std::format 当前实现（libstdc++ 13 / libc++ 18）仍属初期版本，缺少 format string 编译期检查、无 zero-cost abstraction 路径。更务实的选择是：
- 继续用成熟的
fmt::format（v10+ 支持 compile-time format string 验证，且默认禁用 locale，性能稳定压过std::format） - 对极致性能要求场景，用宏 +
snprintf手动缓冲（如LOG_INFO("value = %d, flag = %s", x, flag ? "on" : "off")），避免任何模板实例化开销 - 若必须用标准库，可用
std::to_string+operator+拼接简单值（仅限整数、浮点等 POD 类型），避开std::format解析器——虽然丑，但快
std::format_error 异常会破坏日志可靠性
日志函数本该“尽力而为”，但 std::format 在格式串非法（如 "{x}" 中未定义 x）、参数类型不匹配、缓冲不足时抛出 std::format_error。线上服务中，一个错写的日志语句可能让整个线程崩溃。解决方式只有两个：
- 所有日志调用包裹
try/catch，捕获std::format_error后降级为原始参数打印（如"[format_error] args: " ） - 完全禁用异常：编译时定义
_GLIBCXX_USE_CXX11_ABI=0（GCC）或使用 libc++ 并链接-lc++abi，但这不能阻止异常抛出，只是改变 ABI 行为——真正可靠的做法仍是静态检查格式串，比如用 clang 插件或 CI 阶段调用clang++ -Xclang -verify-format-strings
真正影响日志速度的，从来不是格式化函数选哪个，而是是否引入了同步等待、是否重复构造临时字符串、是否在临界区做格式化。C++20 的 std::format 目前更适合替代 std::ostringstream 做配置打印或调试输出，而不是扛起高频日志的重担。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
