因为每次+=可能触发内存重分配，而reserve预分配足够空间后所有追加都在同一块内存完成，避免重复拷贝；关键要求是reserve容量≥最终总长度，且append比+=更确定高效。
为什么std::string::reserve()比反复+=快得多
因为每次+=可能触发内存重分配，而重分配涉及旧数据拷贝、新内存申请、旧内存释放三步开销。当拼接次数多、单次字符串短时，这种开销会指数级放大。预分配足够空间后，所有追加操作都在同一块连续内存中完成，避免了重复拷贝。
关键不是“reserve 之后就一定快”，而是“reserve 的容量必须 ≥ 最终总长度”。如果预估不足，仍会中途扩容；如果过度预留（比如翻倍预估），又浪费内存。
-
reserve()只改变容量（capacity），不改变长度（size）；调用后size()仍是 0 - 预估总长时，别漏掉分隔符、换行符等额外字符（比如拼接 10 个
"abc"加逗号分隔，实际需 10×3 + 9 = 39 字节） - 若总长完全未知，但知道上限（如日志行不超过 4KB），可直接
reserve(4096)，比动态扩容更可控
用std::string::append()代替+=提升确定性
+=本质是调用operator+=，其内部可能做额外类型推导或临时对象构造；而append()明确接受const char*、std::string_view或迭代器范围，编译器更容易内联且无隐式转换开销。
尤其在循环拼接中，append()配合预分配能稳定维持 O(1) 平摊复杂度；+=在某些标准库实现下（如老版本 libstdc++）甚至可能退化为 O(n²)。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 优先用
s.append(str.c_str(), str.size())而非s += str - C++17 起支持
s.append(std::string_view{data, len})，零拷贝传入原始缓冲区 - 避免在循环内写
s += "literal" + std::to_string(i)——+会创建临时std::string，再拷贝进s，白费一次分配
手动管理缓冲区：用std::vector<char></char>绕过std::string的构造开销
当拼接逻辑极频繁（如序列化万级对象）、且最终只需 C 风格字符串或二进制数据时，std::vector<char></char>比std::string更轻量：它不维护c_str()缓存，也不保证末尾有'\0'，少了语义约束，写入更快。
典型场景：生成 JSON 数组、打包网络协议包、构建 SQL 批量插入语句。
- 先
vec.reserve(total_estimated_size)，再用vec.insert(vec.end(), data.begin(), data.end())或std::copy追加 - 完成后用
std::string{vec.data(), vec.size()}一次性构造结果（仅一次内存拷贝） - 若后续只读，可直接用
std::string_view{vec.data(), vec.size()}避免拷贝 - 注意：
vec.data()在push_back()或resize()后可能失效，务必在所有写入完成后才取指针
常见误判：std::ostringstream不适合极速拼接
很多人以为std::ostringstream是“高级拼接工具”，但它底层基于std::stringbuf，默认缓冲区小（通常 128–512 字节），且每次都可能触发扩容+格式化+字符转换，比原生<code>append()慢 3–10 倍。
它适合需要格式化（如ss ）且拼接量小的场景，而非“极速”需求。
- 不要用
oss 替代<code>s.append(s1).append(s2).append(s3) - 即使调用
oss.str().reserve()也无效——str()返回的是副本，不影响内部缓冲区 - 真要用流，得自定义
std::streambuf并绑定大缓冲区，代价远超直接操作std::string
+=或隐式转换，前面的优化就全白做了。 
