std::string::append在循环中反复调用变慢是因为每次容量不足时触发内存重分配，涉及申请新内存、拷贝旧内容、释放旧内存；预分配capacity可避免该开销，但需合理估算长度并避免临时对象构造。
为什么std::string::append在循环中反复调用会变慢
因为每次append都可能触发内存重分配——当当前容量不足时，std::string会申请新内存、拷贝旧内容、释放旧内存。这个过程在小字符串高频拼接时开销显著，尤其在未预留空间的情况下。
典型场景：读取多行日志、拼接JSON字段、构建SQL语句。实测中，10万次append未预分配比预分配慢3–5倍（取决于编译器和STL实现）。
- 默认构造的
std::string初始容量通常为0或15（small string optimization阈值），远低于实际需求 -
capacity()增长策略不固定：libc++常翻倍，libstdc++可能1.5倍，无法预测单次扩容成本 - 即使使用
+=，底层仍调用append，问题本质相同
用reserve()提前锁定容量，但别过早或过量
reserve()只改变容量（capacity），不改变长度（size），是零成本的元操作；但它不能替代resize()——后者会初始化字符并改变size，反而浪费。
关键点：预估总长度要略宽松，但别盲目放大。例如拼接100个平均长20的字符串，总长≈2000，reserve(2200)比reserve(10000)更优——后者可能引发一次大内存分配，且后续append仍需检查边界。
立即学习“C++免费学习笔记（深入）”；
- 若总长度可精确计算（如已知所有片段长度），直接
s.reserve(total_len) - 若只能估算，加10%–20%余量即可；超过30%余量通常得不偿失
- 调用
reserve()后，只要总追加长度≤容量，append就是O(1) memcpy，无重分配
避免append传入临时std::string对象
写成s.append(std::string("hello") + " world")或s.append(get_temp_string())，会导致额外构造+销毁临时对象，还可能触发不必要的内存分配——即使s已reserve好。
正确做法是让append直接处理原始数据源：
- 用
append(const char*, size_t)代替append(std::string)，跳过临时对象构造 - 对C字符串字面量，优先用
append("xxx")（编译器识别为const char*重载） - 若来源是
std::string_view，直接append(sv)——零拷贝，且不触发内部std::string构造
示例：
// 差：创建临时string再append
s.append(std::string("key:") + key + "=" + value);
// 好：分段append，避免临时对象
s.append("key:");
s.append(key);
s.append("=");
s.append(value);
当拼接模式固定时，考虑std::ostringstream或自制缓冲区
如果拼接逻辑含大量格式化（如数字转字符串、带分隔符）、且无法静态预估长度，std::ostringstream内部也做了容量管理，但默认策略偏保守。此时手动控制更稳：
- 对纯字符串拼接，坚持
reserve+ 多次append仍是最快路径 - 若涉及
int/double等转字符串，先用std::to_string或std::format（C++20）生成std::string_view再append，别让流自己反复扩容 - 极端性能敏感场景（如高频日志），可封装一个简易缓冲类，用
char*+size_t管理，配合snprintf或std::to_chars写入，绕过STL开销
真正容易被忽略的是：预分配不是万能解药。如果拼接前就频繁调用clear()或erase()，capacity()可能被STL实现收缩（虽然标准不强制，但某些libstdc++版本会），导致下次reserve前的append又触发分配。这时候得用shrink_to_fit()之后再reserve，或者干脆复用同一实例不clear。
