预分配内存是提速前提，不reserve性能会断崖式下跌；reserve只改capacity不改size，需先累加总长（用size_t防溢出）、再调reserve、最后用append（带长度参数）避免隐式开销。
预分配内存是提速前提，不 reserve 就别谈高效
没调 reserve() 的大量拼接，性能会断崖式下跌——不是慢 2 倍，是可能从毫秒级拖到秒级。原因很简单：std::string 默认按翻倍策略扩容，拼接 100 万次、每次 1KB，中间可能触发数十次 realloc + 全量 memcpy，最后还可能因碎片或单次大分配失败而抛 std::bad_alloc。
关键点：
-
reserve()只影响容量（capacity()），不改变长度（size()），也不初始化内存 - 传入值宁大勿小：低估会导致二次扩容；高估最多浪费点内存，但避免了拷贝开销
-
reserve(0)合法但无效，必须传明确的预估上限 - 多线程写同一
std::string时，reserve()本身不线程安全，仍需外部同步
append() 比 += 更可控，参数选错就白优化
append() 和 += 在底层行为上几乎一致，但 append() 提供更精细的重载控制，能彻底避开隐式开销。尤其在高频循环中，一个参数细节就能让百万次拼接多出几毫秒延迟。
常见错误与建议：
- 写
result.append("hello")→ 编译器虽常优化，但语义上仍要扫描 null terminator；改用result.append("hello", 5)或result.append(std::string_view{"hello"}) - 拼
const char*且长度已知时，绝不能漏掉长度参数——这是最易被忽略的性能开关 - 子串来自
std::string& s，优先用result.append(s)（支持移动或引用）；避免result.append(s.c_str())，它又触发一次strlen() - 固定模式重复拼接（如
"abc"重复n次），直接算static_cast<size_t>(n) * pattern.size()</size_t>，别用int中间变量
累加总长必须用 size_t，整数溢出会让 reserve 失效
拼接 100 万次、每次 1KB，总长是 1,024,000,000 字节——这已接近 int 上限（2,147,483,647）。若用 int 累加，中间溢出后传给 reserve() 的可能是负数或极小值，后续 append() 立即崩溃。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
安全做法：
- 统一用
size_t或uint64_t累加长度，尤其当子串来源含std::string_view::size()、strlen()或用户输入的重复次数时 - 累加前做饱和检查：若当前和 >
SIZE_MAX - next_part.size()，应拒绝拼接或切分任务 - 对来自用户或配置的重复次数，不做信任型转换：
static_cast<size_t>(n)</size_t>前先验证n >= 0
什么时候不该用 reserve + append
不是所有场景都适合预分配。有些拼接根本无法预估总长，比如流式解析 JSON 字段名+值、协议头动态填充、模板引擎边解析边生成——硬要 reserve() 反而导致大块内存长期占用，甚至因预估过大引发 OOM。
此时可选替代方案：
-
std::ostringstream：适合混合类型拼接（数字/布尔/字符串），但实测比预分配append()慢 3–8 倍，构造和.str()都有额外开销 -
std::format（C++20）或fmt::format：兼顾类型安全与性能，比stringstream快 5–10 倍，接近手写append，但需引入标准库或第三方依赖 - 分段拼接 +
shrink_to_fit()：对超长任务拆成若干块，每块单独reserve+append，完成后调shrink_to_fit()释放冗余容量
真正容易被忽略的是：预分配只解决扩容问题，不解决内容拷贝本身。如果拼接项本身是短小、高频、固定的小字符串（比如日志前缀），编译器在 -O2 下可能把连续 append() 优化为单次 memcpy；但一旦中间夹杂条件分支或函数调用，这种优化就失效了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
