std::string默认拼接在高频场景下变慢是因为每次容量不足时触发内存重分配和数据拷贝，导致O(n²)开销；应预先reserve()总长度，用data()指针写入后resize()设置有效长度。
为什么std::string默认拼接在高频场景下会变慢
每次调用 += 或 append() 时，std::string 若当前容量不足，会触发内存重新分配 + 数据拷贝。频繁小段拼接（比如循环中逐个追加短字符串）会导致 O(n²) 拷贝开销——不是因为算法复杂，而是因为反复 realloc 和 memcpy。
典型症状：循环 10 万次拼接平均长度 5 字符的字符串，耗时可能从毫秒级跳到百毫秒级，且性能曲线非线性恶化。
- 标准库不保证
reserve()后的 capacity 一定等于你传入值（可能向上对齐，如对齐到 16/32 字节边界） -
reserve()不改变size()，只是预留空间；未初始化内存不可读，但可安全写入 - 若预估偏差过大（比如预估 1MB 实际只用 10KB），浪费内存但无性能损失；反之则仍会 realloc
如何用reserve() + data()绕过多次分配
核心思路：一次性预分配足够大的缓冲区，用指针直接写入，最后用 resize() 告诉 string 当前有效长度。避免所有中间 append() 的检查和边界调整。
示例：拼接 5000 个已知长度的 const char*：
立即学习“C++免费学习笔记（深入）”；
std::string result;
size_t total_len = 0;
for (const auto& s : str_vec) total_len += strlen(s);
result.reserve(total_len); // 一次分配
<p>char* p = result.data();
for (const auto& s : str_vec) {
size_t len = strlen(s);
memcpy(p, s, len);
p += len;
}
result.resize(total_len); // 设置最终 size</p>- 必须用
data()获取可写指针，c_str()返回 const 指针，不能写 - 不能在
reserve()后调用任何可能引起 reallocation 的操作（如再+=一个字符串） -
resize()是关键收尾动作，否则result仍为空字符串（size()为 0）
使用std::string_view预计算总长时的陷阱
当输入是 std::string_view 数组时，.size() 安全高效，但要注意其底层数据生命周期必须长于拼接过程。
常见错误：
std::string temp = "hello"; std::string_view sv(temp); // OK // ... 但如果 temp 在拼接前被销毁，sv 成悬垂指针
- 不要把临时
std::string转成string_view后存入待拼接列表——除非确保原字符串不析构 -
string_view::data()不保证以\0结尾，用memcpy没问题，但别误当 C 字符串用strlen - 若部分输入是
std::string、部分是字面量，统一转string_view计算总长更简洁，但注意类型擦除成本几乎为零
多线程环境下预分配拼接的注意事项
预分配 + 指针写入本身是线程安全的，前提是每个线程操作独立的 std::string 对象。但共享同一个 string 并发写入会崩溃。
- 绝对不要让多个线程共用一个
result并各自调用data()写入不同偏移——无锁但不安全，没有原子边界保护 - 如果必须合并多线程结果，推荐各线程先拼好自己的子串，主线程再用预分配拼接这些子串（两次预分配：子串 + 最终串）
-
reserve()在多线程中调用是安全的，但结果 capacity 可能因内部对齐策略在线程间略有差异，不影响正确性
真正容易被忽略的是：预分配后忘记 resize() —— 这会让整个拼接结果为空，且无编译或运行时提示，调试时极难定位。
