reserve()不能直接加速拼接，因其仅预分配内存而不保证零拷贝，必须确保预估总长不小于实际拼接长度；需准确累加所有子串（含变量、to_string结果、字面量）长度，避免运行时扩容。
为什么 std::string::reserve() 不能直接加速拼接？
很多人以为调用 reserve() 后，后续 += 或 append() 就一定零拷贝——其实不然。如果拼接过程中触发了内部缓冲区扩容（比如 reserve() 申请了 100 字节，但某次 append() 写入后总长超 100），仍会重新分配并复制旧内容。关键在于：预分配必须覆盖「最终总长度」，且后续所有写入都不能超出该容量。
如何准确计算拼接后的总长度？
常见错误是只累加字符串字面量长度，忽略变量字符串的运行时长度。尤其当拼接含 std::string 变量、std::to_string() 结果或 C 风格字符串时，必须在预分配前完成全部长度计算。
- 用
std::string::size()获取每个字符串当前长度，别用strlen()处理std::string.c_str() - 对数字转字符串，先调用
std::to_string(x).size()，不要假设 int 总是 11 字节（负数多占 1 位） - 若拼接含格式化内容（如
"id=" + std::to_string(id) + ",name=" + name），把所有+拆成独立长度求和，避免临时对象销毁导致重复计算
推荐写法：先 reserve，再 append，禁用 +=
+= 在某些 libstdc++ 实现中可能绕过 capacity 检查，而 append() 更稳定；同时，一次性 reserve() 比多次小幅度扩容高效得多。
std::string result;
size_t total_len = str1.size() + str2.size() + std::to_string(num).size() + 5; // "key=" + ":" 占 5
result.reserve(total_len);
result.append(str1);
result.append(str2);
result.append(std::to_string(num));
result.append("key=");
result.append(":");
注意：reserve() 不改变 size()，所以后续 append() 是安全的；而如果误用 resize()，会填充值（如 '
注意：reserve() 不改变 size()，所以后续 append() 是安全的；而如果误用 resize()，会填充值（如 '\0'），导致输出异常。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
哪些场景下预分配反而更慢？
短字符串（通常 ≤ 15–22 字节，取决于 small string optimization 实现）走栈内存储，reserve() 强制堆分配反而增加开销。另外，若拼接逻辑分支多、长度难预测（如日志消息含可选字段），硬预分配可能浪费内存或引发重算。
- 目标总长
字节时，直接用 <code>operator+=通常更快 - 不确定长度但有上限，可用
reserve(max_possible)，但需权衡内存占用 - 频繁构造同模式字符串（如 HTTP 响应头），建议封装为函数，把长度计算和 reserve 提前固化
真正省时间的地方，不是避免一次分配，而是避免多次 realloc + memcpy —— 这点容易被 benchmark 里的微秒级差异掩盖，但在高频循环里会累积成显著延迟。
