直接用append拼接大量字符串会慢，因为std::string默认按需扩容，每次容量不足时触发内存重分配、拷贝旧内容，循环中多次realloc使时间复杂度退化为o(n²)；预分配reserve(total_len)可避免该开销，使后续append均为o(1)均摊操作。
为什么直接用 append 拼接大量字符串会慢？
因为 std::string 默认按需扩容，每次容量不足时会重新分配内存、拷贝旧内容——尤其在循环中反复 append 小字符串时，可能触发多次 realloc，时间复杂度退化为 O(n²)。
典型错误写法：
std::string s;<br>for (const auto& part : parts) {<br> s.append(part); // 每次都可能 realloc<br>}
- 扩容策略通常为 1.5× 或 2×，但初始容量小（如 15 字节），几十次拼接就可能触发 5–10 次内存分配
- 即使最终总长已知，不预分配也会浪费 CPU 在 memcpy 上
-
+=和append在底层行为一致，无本质区别
如何用 reserve 预分配避免重复扩容？
在拼接前调用 reserve 显式预留足够空间，后续所有 append 都在原缓冲区内完成，消除 realloc 开销。
关键点：reserve 只影响容量（capacity），不影响长度（size）；它不初始化内存，也不改变当前内容。
- 若能提前知道总长度（如所有
part.size()之和），直接s.reserve(total_len) - 若无法精确计算，可保守估算（例如 +10%），避免过度预留导致内存浪费
- 不要用
resize替代reserve：后者会填充值（如 '\0'），且后续append仍会从末尾开始写，但中间填充字节可能干扰逻辑
正确示例：
size_t total_len = 0;<br>for (const auto& part : parts) total_len += part.size();<br>std::string s;<br>s.reserve(total_len); // 仅此一行，效果显著<br>for (const auto& part : parts) {<br> s.append(part); // 全部 in-place，O(1) 均摊}
append 的重载选择影响性能吗？
影响很小，但选错可能隐式触发额外构造或转换。优先使用最匹配的重载，避免隐式 std::string 构造。
- 拼接 C 风格字符串：用
s.append("hello")（const char*重载），而非s.append(std::string("hello")) - 拼接
std::string_view（C++17+）：用s.append(sv)，零拷贝且不依赖空终止符 - 拼接子串：用
s.append(other, pos, len)，比先构造临时substr()再append更高效 - 避免
s.append(1, 'x')这类单字符追加——直接用s.push_back('x')更轻量
多线程环境下 reserve + append 安全吗？
不安全。std::string 非线程安全，即使只读访问 capacity() 或 size() 也需同步；reserve 和 append 都会修改内部状态。
- 若必须并发拼接，不要共享同一
std::string对象 - 推荐每个线程独立构造字符串，最后用
std::string::operator+=合并（合并次数远少于拼接次数） - 或改用无锁结构（如
absl::StrCat）或预先分配好 buffer 的自定义拼接器
常见误判：reserve 是 const 操作？不是——它可能触发 reallocation，属于非 const 修改。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
