std::String::reserve()仅预分配内存，不改变拼接逻辑；须在拼接前调用且预估总长准确，否则仍可能触发重分配；对小字符串优化场景可能无效；纯字符串拼接且长度已知时，reserve()+ += 比stringstream更快。
为什么 std::string::reserve() 不能直接加速拼接过程
很多人以为调用 reserve() 后，后续的 += 或 append() 就“自动变快”，其实不是——它只预分配内存，不改变拼接逻辑本身。如果拼接次数多、每次追加短字符串（比如循环中拼数字），仍可能反复触发小规模重分配（尤其未 reserve 前），但 reserve 之后，只要总长没超容量，就真的一次分配、零 realloc。
- 必须在拼接开始前调用，且预估总长度越准，浪费越少；低估会回退到默认增长策略（通常是 1.5× 或 2×）
-
reserve(0)不清空内容，也不释放内存；clear()后 capacity 通常不变 - 对短字符串（
sizeof(std::string) == 24的小字符串优化场景），reserve 可能完全无效——数据存在对象内部，压根不走堆分配
什么时候该用 std::stringstream 而不是手动 +=
std::stringstream 真正的优势不在“拼接”，而在“格式化混合输入”：比如把 int、double、const char* 和变量名混在一起转成日志字符串。它底层也用 std::string 缓冲，但每次写入都会检查容量并扩容，没有显式 reserve 接口。
- 纯字符串拼接（全是
std::string或 C 字符串）+ 已知总长 → 手动reserve()++=更快，少一层流操作开销 - 含格式化（如
ss ）→ <code>std::stringstream更安全简洁，避免std::to_string多次构造临时对象 - 注意
ss.str().c_str()返回的是副本的指针，生命周期仅限于该表达式；要长期持有需赋值给std::string变量
实测性能差异的关键条件
速度对比结果高度依赖编译器优化等级、字符串长度分布、拼接次数和是否启用小字符串优化（SSO）。在 -O2 下，以下情形有明显分水岭：
- 拼接 100 次、每次 4 字节 →
reserve()++=比stringstream快 2–3× - 拼接 5 次、含
double和bool→stringstream代码更短，性能差距不到 10%，可忽略 - 目标字符串最终长度 > 256 字节且拼接次数 > 1000 → 必须
reserve()，否则+=可能慢 5× 以上（因多次 realloc + memcpy） - Clang 15+ 对
operator+=有更强的内联优化，GCC 12 在-O2下对stringstream的缓冲管理更激进
一个容易被忽略的坑：std::string 移动语义失效场景
如果你写的是 result += std::to_string(x) + " ";，中间的 std::to_string(x) + " " 是临时对象，但 += 接收的是 const lvalue 引用，不会触发移动——实际执行的是拷贝构造 + 追加。这会让 reserve 的收益打折扣。
立即学习“C++免费学习笔记（深入）”；
- 改用
result.append(std::to_string(x)).append(" ");，两个append()都接受右值引用重载，能真正移动 - 或者拆成两步：
auto s = std::to_string(x); result += s; result += " ";，虽然多一个变量，但第二步+= s是移动（c++17 guaranteed copy elision + move overload） - 别依赖 IDE 提示说“已优化”，用
-fsanitize=undefined或 perf record 看实际 memcpy 次数才靠谱
字符串拼接不是非此即彼的选择题，而是得看数据来源、类型混合度和最终长度分布。reserve 不是银弹，stringstream 也不是万金油——最慢的往往是没做任何预估、纯靠默认行为撑下来的代码。