append频繁触发内存重分配是因为初始容量小，倍增扩容需反复分配+memcpy旧数据；预分配需在append前用reserve()精确计算总长，避免O(n²)拷贝。
为什么append频繁触发内存重分配？
当你连续调用 std::string::append（或 +=）拼接多个小字符串时，底层可能反复执行内存分配 + 数据拷贝。标准库通常采用倍增策略（如 1.5× 或 2× 扩容），但若初始容量为 0，第一次 append 就要分配、第二次可能再分配……最终实际分配次数远超必要值。
关键不是“每次 append 慢”，而是“扩容时要把旧数据 memcpy 到新地址”——这部分开销随字符串长度增长而显著上升。
- 默认构造的
std::string容量常为 0 或 15（SSO 临界点），append一上来就触发首次分配 - 若拼接总长可预估（比如日志格式固定、JSON 字段名已知），不预分配等于主动放弃控制权
-
reserve()只影响 capacity，不影响 size，是零成本的“占位”操作
预分配前必须知道总长度：几种可靠计算方式
不能靠猜，也不能靠运行时累加——那和不预分配没区别。得在调用 append 前就拿到精确或足够大的上界。
- 静态拼接（如
"HTTP/1.1 " + status_code + " " + reason）：用strlen或sizeof算字面量长度，加上变量的size() - 循环拼接（如 vector
合并）：先遍历求和所有 s.size()，再调用reserve(total) - 含格式化内容（如
printf风格）：用snprintf(nullptr, 0, ...)获取所需长度（注意 C++20 的std::format也支持std::formatted_size） - 保守策略：若无法精算，按最大可能值 + 10%~20% 预留，比反复 realloc 更稳
reserve() 调用时机与常见误用
必须在任何 append / += / push_back 之前调用，且只调一次（多次 reserve 不报错但无意义，甚至可能因内部策略导致额外移动）。
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
s.append(a); s.reserve(s.size() + b.size()); s.append(b);—— 第一次 append 已经触发了一次分配 - 正确顺序：
s.reserve(total_len); s.append(a); s.append(b); s.append(c); - 注意 SSO（Small String Optimization）：若预分配长度 ≤ SSO 阈值（常见为 22 或 23 字节），
reserve可能被忽略，但不会出错；超过后才真正分配堆内存 - 避免对空串反复
reserve(1)：这毫无意义，capacity 可能根本不变
对比：reserve + append vs operator+ vs std::ostringstream
三者性能差异极大，尤其在多段拼接场景：
-
operator+（如a + b + c）：生成多个临时string，每个都可能触发独立分配，最差情况 O(n²) 拷贝 -
std::ostringstream：内部维护缓冲区，但存在格式化开销、虚函数调用、以及默认 buffer 较小（常需多次扩容） -
reserve+append：零额外对象、零格式化、可控内存布局，实测在 10+ 段拼接中快 2–5 倍
示例：
std::string result;<br>result.reserve(1024); // 总长预估<br>result.append("key=");<br>result.append(value1);<br>result.append("&flag=");<br>result.append(std::to_string(flag));
预分配这事本身很简单，难的是把“总长估算”这个动作从逻辑里提前抽出来——很多人卡在这一步，不是不会调 reserve，是根本没意识到自己正在让 string 替自己做决策。
