c++oding="utf-8" ?>
reserve仅对多次+=/append且初始容量远小于最终长度的连续拼接有效;若含substr、c_str()或未知长度,则无效甚至浪费内存。

std::string::reserve 为什么不能加速所有拼接场景
直接说结论:reserve 只对「多次 += 或 append 导致反复扩容」的场景有效;如果拼接前已知总长度,且后续不触发 reallocation,它能避免内存重复分配和数据拷贝。但若拼接过程涉及大量小片段、中间有 substr 或 c_str() 调用,reserve 不仅无效,还可能因预留过大造成内存浪费。
什么时候调用 reserve 才真正起作用
关键看扩容是否发生——只有在字符串容量(capacity())不足时追加才会触发 realloc。所以有效前提很具体:
- 目标字符串初始为空或容量远小于最终长度(比如从空开始拼 10KB 文本)
- 所有拼接操作都是连续的
+=/append,中间没调用data()、c_str()或传给 C 接口(某些实现会触发 COW 或去共享状态,间接影响 capacity 判断) - 你确实知道最终长度(或足够上界),比如读取文件前先
stat获取 size,或解析 JSON 前预估 key+value 总长
reserve 后 append 的实际性能差异
以拼接 10 万个短字符串为例(每个约 20 字节):
组合式C++代码评审方案,融合静态分析、AI推理、多轮迭代评审和C++专项检查,适用于PR审查、增量代码审查、全项目评审和代码质量评分,触发词包括review cpp、cpp代码评审、C++review、代码审查。
// 未 reserve:平均触发 17 次 realloc,每次拷贝已有内容 std::string s; for (int i = 0; i // reserve 后:零 realloc,仅 memcpy 新内容到预留位置 std::string s; s.reserve(600000); // 100000 * 6 for (int i = 0; i <p>实测在 libstdc++ 下第二段快 2.3 倍;但若用 <code>std::string_view</code> + <code>std::format</code> 或一次性构造,可能更快——<code>reserve</code> 是低成本优化,不是银弹。</p><h3>容易被忽略的坑:reserve 不等于 resize,也不保证零初始化</h3><p><code>reserve(n)</code> 只改 <code>capacity()</code>,不改 <code>size()</code>,更不会填 '\0';之后访问 <code>s[i]</code>(i ≥ <code>size()</code>)仍是越界行为。常见误用:</p>
- 误以为
reserve(100)后就能安全写s[50] = 'x'→ 实际是未定义行为 - 和
resize(100)混淆:后者会设size() == 100,并用 '\0' 填充(或指定值) - 在多线程中对同一
std::string调用reserve++=:非线程安全,必须加锁或改用局部 string
真正要控制内存布局又需随机写入,得用 resize 或 std::vector<char></char> 配合 data()。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!










