std::format 不会修改全局流状态，而 iostream 的操纵器（如 std::setw、std::setfill）会改变流的持久格式状态，影响后续输出行为。
std::format 不会修改全局流状态，而 iostream 的
std::format 是纯函数式字符串构造，不依赖 std::cout 状态
它只做一件事：把参数按格式说明符拼成一个 std::string（或 std::wstring），完全不碰 std::cout 的 flags()、width()、precision() 等设置。哪怕你之前调用过 std::cout ，对 <code>std::format("{:x}", 42) 也毫无影响。
常见错误现象：
- 误以为
std::cout 后，<code>std::format("{}", 255)也会输出十六进制 —— 实际仍是十进制 - 在多线程中反复调用
std::cout ，结果发现 <code>std::format("{:.2f}", 3.14159)始终稳定输出"3.14"，因为它的精度由格式串决定，不共享流状态
iostream 输出是命令式、带副作用的流操作
每次使用 都可能改变流对象的内部格式标志，且这些标志会持续生效，直到被显式重置。例如：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::cout << std::hex << 255 << ' '; std::cout << 42; // 这里也变成 hex！输出 "ff 2a"，不是预期的 "ff 42"
使用场景差异：
- 需要逐段写入文件或网络 socket 时，
std::ostream&的链式调用更自然 - 仅需构造日志消息再统一处理（如加时间戳、发远程、写磁盘），
std::format更可控、无状态污染 - 频繁切换进制/精度/填充时，流操作容易漏掉
std::dec或std::resetiosflags，而std::format每次都是干净的
编译期检查 vs 运行时状态依赖
std::format 的格式字符串是字面量（或 consteval 表达式）时，编译器能静态验证占位符数量、类型匹配和格式语法；而 std::ostream 的 操作只能在运行时推导类型，出错时表现为静默截断、乱码或崩溃（比如 <code>std::cout (0x123) 在某些平台输出异常）。
容易踩的坑：
- 混合使用：
std::cout 看似方便，但丢失了 <code>std::format的独立性优势，且仍要承担流状态干扰风险 - 误用
std::ostringstream模拟std::format：代码更长、性能更低、仍受流标志影响（oss 同样会污染后续插入） - 想用
std::format但传入运行时字符串（如用户输入的模板）：必须改用std::vformat+std::make_format_args，否则编译失败
最常被忽略的一点：即使你只用 std::format 构造字符串，如果最终还要塞进 std::cout 输出，那流本身的缓冲策略（std::cout.sync_with_stdio(false)）、locale、异常掩码等，依然会影响最终显示效果——std::format 只管“造字”，不管“发声”。
