直接用append多次拼接性能差，因std::string默认动态扩容，每次append可能触发内存重分配和数据拷贝；若已知最终长度，应先reserve再append，避免冗余realloc。
为什么直接用 append 多次拼接性能差？
因为 std::string 默认在堆上动态扩容，每次 append 都可能触发内存重分配和数据拷贝。比如循环 100 次调用 append("a")，底层可能 realloc 5–10 次，实际拷贝字节数远超最终长度。
常见错误现象：append 在循环里反复调用后，性能比预期慢几倍甚至几十倍，尤其当目标字符串初始为空或容量很小时。
- 每次
append前检查当前capacity()是否足够，不够就扩容 - 扩容策略通常是“翻倍”，但小字符串频繁触发会导致大量冗余拷贝
- 如果已知最终长度（比如拼接 N 个固定子串），应提前预留空间
如何用 reserve 配合 append 实现高效拼接？
核心是让 append 不触发扩容——先算总长，再用 reserve 一次性分配够内存。
使用场景：拼接次数确定、子串长度可预估（如日志组装、协议包构造、模板填充）。
立即学习“C++免费学习笔记（深入）”；
- 先遍历所有待拼内容，累加长度（注意：
std::string_view或 C 字符串需用.size()或strlen） - 调用
str.reserve(total_len)，不是resize—— 后者会填零并改变size() - 再逐次
append，此时只要不超capacity()就不会 realloc
示例：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::string result; size_t total = len1 + len2 + len3; // 已知各段长度 result.reserve(total); result.append(str1); result.append(str2); result.append(str3); // 三次 append 全部 O(1) 拷贝
append 的参数选择影响拷贝效率
不同重载版本的 append 底层行为差异明显，选错会多一次临时构造或隐式转换。
容易踩的坑：传 std::string 对象而非 std::string_view 或 C 字符串指针，尤其在循环中。
- 优先用
append(const char*, size_t)或append(std::string_view)，避免构造临时std::string - 避免
append(std::string&)在循环中——它会复制整个对象，哪怕只是追加几个字符 - 若子串来自
char*且长度已知，务必传入长度，否则append(const char*)会调用strlen多扫一遍
对比：
// 慢：隐式构造 string，再拷贝
result.append("hello");
<p>// 快：直接按字面量地址+长度处理（编译器优化后等价于 const char* + size_t）
result.append("hello", 5);</p><p>// 更通用且安全（C++17 起推荐）
result.append(std::string_view{"hello"});什么情况下不该用 reserve + append？
当拼接逻辑复杂、长度无法静态预估（比如嵌套条件分支、运行时读取变长数据），硬算 total_len 容易出错或引入额外开销。
此时不如交给 std::string 自己管理，但可通过其他方式缓解：
- 初始
reserve一个合理下限（如 256 或 1024），避免前几次小 append 频繁扩容 - 用
+=替代append语义更清晰，性能无差别（+=内部就是调append） - 极端场景（百万级拼接）考虑
std::ostringstream或第三方库（如absl::StrCat），它们做了更精细的容量预测
真正容易被忽略的是：即使用了 reserve，如果后续又调了 clear() 或 erase()，容量不变但 size() 归零，再次 append 仍可能触发扩容——得重新 reserve 或用 shrink_to_fit()（但后者不保证释放内存）。
