频繁字符串拼接应优先用 append 或 += 而非 +，因其复用缓冲区、避免多次分配；已知长度时调用 reserve 预分配；ostringstream 仅适用于需格式控制的场景；string_view 不支持直接拼接且需确保生命周期；std::format 适合低频高安全性场景而非高频拼接。
用 std::string::append 或 += 比 + 运算符快得多
频繁用 + 拼接字符串会反复构造临时对象、多次分配内存，尤其在循环里性能断崖式下跌。编译器很难优化这种链式加法，因为每个 + 都要返回新 std::string。
实操建议：
- 循环内拼接，一律改用
str.append(other)或str += other—— 它们复用已有缓冲区，不产生额外拷贝 - 如果已知最终长度，提前调用
str.reserve(n)，避免多次扩容（每次扩容通常是 1.5× 或 2× 原容量） - 避免写
s = s + a + b + c；改成s += a; s += b; s += c;
拼接大量小字符串时，std::ostringstream 不是万能解
很多人以为 std::ostringstream 是“安全又高效”的通用方案，实际它内部维护格式状态、缓冲管理开销大，在纯字符串拼接场景下比直接操作 std::string 慢 2–5 倍。
适用场景有限：
立即学习“C++免费学习笔记（深入）”；
- 需要混合拼接数字/浮点数且依赖格式控制（如
std::hex、std::setw）时才值得用 - 纯字符串追加（比如日志组装、路径拼接），直接用
std::string+reserve+append更轻量 - 若使用
std::ostringstream，记得调用.str()前先.flush()，否则可能丢数据（尤其多线程下未同步时）
std::string_view 能省拷贝，但不能直接拼接
std::string_view 本身没有拼接能力，传给 append 或 += 是零成本的（只是指针+长度），但它指向的内容生命周期必须长于拼接操作本身。
常见错误现象：
- 把局部
char[]或临时std::string的data()构造成string_view后存起来，后续拼接时访问野内存 - 误以为
sv1 + sv2会返回string_view—— 实际上这行不通，C++20 前连重载都没有，编译直接报错：no match for 'operator+' - 想“零拷贝拼接”，得自己管理生命周期，或转成
std::string再拼（此时拷贝不可避免）
C++20 std::format 适合格式化，不适合高频拼接
std::format 语义清晰、类型安全，但目前主流实现（libstdc++/libc++）底层仍基于动态分配和格式解析，单次调用开销远高于 append。它不是 snprintf 的零成本抽象。
性能影响明显：
- 拼接 10 个字符串，
std::format("{}", s1) + std::format("{}", s2)比s1 + s2慢 8 倍以上 - 调试构建下更慢，因为格式验证逻辑全开启
- 仅推荐用于：日志输出、错误信息生成等对吞吐不敏感、但对可读性/安全性要求高的场景
真正影响性能的从来不是“用哪个函数”，而是“是否让内存分配失控”。预留容量、避免临时对象、盯住生命周期——这些细节比选 API 更关键。
