std::string::reserve()仅预分配容量不改变size，循环拼接中若未预先精确计算总长并一次性reserve，则仍可能多次重分配；正确做法是先累加所有片段长度（含分隔符），再调用reserve()，之后用append()或+=。
为什么 std::string::reserve() 不能替代拼接时的预分配
直接调用 reserve() 只是预留底层缓冲区容量，并不改变 size()，后续每次 += 或 append() 仍可能触发多次重分配——尤其在循环拼接中，若未预估总长，reserve() 的效果会被后续增长行为抵消。
真正起效的前提是：在所有拼接开始前，已知最终字符串总长度（或足够上界），且所有拼接操作都复用同一 std::string 对象。
- 错误做法：
s.reserve(100); for (auto& part : parts) s += part;—— 若parts元素数量多、长度波动大，+=内部仍可能因内部逻辑（如 SSO 切换、增长策略）导致额外拷贝 - 正确前提：先累加所有待拼接片段长度，再
reserve()，之后统一用append()或operator+=（二者在已预留足够空间时行为一致） - 注意：
reserve(0)不释放内存，shrink_to_fit()才可能释放，但不保证成功
std::string 拼接时如何准确计算预留长度
关键不是“大概估”，而是避免重复遍历和隐式转换开销。比如对 std::vector<:string></:string> 拼接，应一次性算出总长，而非边拼边加。
常见错误是调用 part.length() 多次（尤其在 range-for 中），或误用 std::accumulate 配合 + 导致临时对象构造。
立即学习“C++免费学习笔记（深入）”；
- 安全做法：
size_t total_len = 0; for (const auto& s : parts) total_len += s.size();
然后result.reserve(total_len) - 慎用
std::string_view输入：若片段来自string_view，直接用.size()，无需转std::string - 分隔符要计入：如用
"|"连接n个字符串，需加(n-1) * sep.size()，别漏掉
使用 std::ostringstream 还是原生 std::string 拼接
std::ostringstream 默认底层用 std::stringbuf，其内部也做动态增长，但不可控；且格式化（如 ）引入类型擦除和流操作开销，纯字符串拼接场景下明显更慢。
实测（Clang 16, -O2）：拼接 10k 个短字符串，原生 string::append() 比 ostringstream 快 2–3 倍，内存分配次数少 90% 以上。
- 只在需要格式化（数字转字符串、宽度控制、进制切换）时才用
ostringstream - 若必须用流，可提前
oss.str().reserve(N)，但无效——str()返回副本，不影响原 buffer；正确方式是oss.rdbuf()->pubsetbuf(nullptr, N)（非标准、不可靠） - 更稳妥的流替代：C++20
std::format（支持编译期格式串），但目前 GCC/Clang 实现仍有堆分配，不适合高频拼接
移动语义能否优化多次拼接性能
对单次拼接，std::move(s1) + s2 可避免 s1 的拷贝，但仅限于右值；而循环中反复拼接时，移动无意义——因为目标 std::string 是左值，且每次 += 已是就地修改。
真正有效的移动发生在“拼接结果传出”环节：比如函数返回拼接好的字符串，应直接 return result;（C++17 guaranteed copy elision），而非 return std::move(result);（反而禁用 NRVO）。
- 错误直觉：“用
std::move让 append 更快” ——append(string&&)重载只对传入右值有用，对循环内变量无效 - 唯一适用场景：拼接完后，将结果移给另一个容器，如
vec.push_back(std::move(result)) - SSO（Small String Optimization）影响：短字符串（通常 ≤22 字节）根本不动态分配，此时
reserve()无意义，过度预分配反而浪费栈空间
预分配本身不难，难的是判断“何时真需要”以及“长度估得准不准”——特别是当输入来自网络、文件或用户输入时，长度不确定反而比多一次分配代价更高。
