std::string::reserve 不能直接提速拼接，因其仅预分配内存而不改变 size() 或自动追加内容；需配合顺序追加（如 +=）才减少重分配，且须在赋值前调用以避免预留失效。
std::string::reserve 为什么不能直接提速拼接？
调用 reserve 只是预分配内部缓冲区，避免多次内存重分配，但它不改变 size()，也不自动追加内容。如果你用 += 或 append 拼接，reserve 确实能减少 reallocation 次数；但若频繁调用 push_back 单字符，或中间穿插 substr/erase，预留空间可能很快失效。
- 适用场景：已知最终长度（或上限），且拼接方式是顺序追加（如循环中
str += piece） - 错误用法：先
reserve(100)，再str = "hello"—— 赋值会丢弃预留空间，重新分配 - 检查是否生效：拼接后对比
str.capacity() >= expected和str.size()
std::stringstream 在什么情况下反而更慢？
std::stringstream 内部维护格式化状态、locale、读写缓冲区，启动开销大。它适合「混合类型转字符串」（如数字+文本+变量），但纯字符串拼接时，每调用一次 都可能触发小块内存分配和流状态检查。
- 优势场景：拼接含
int、double、bool的表达式，例如ss - 劣势场景：仅拼接多个
std::string或字面量，比如ss —— 此时reserve++=快 2–5 倍 - 可优化点：构造时传入空字符串避免默认初始化开销：
std::stringstream ss{""}
真正高效的拼接：std::string + reserve + 移动语义
最轻量、可控性最强的方式是手动管理容量，并利用 C++11 后的移动拼接。尤其当源字符串是临时量（如函数返回值）时，+= 会触发移动而非拷贝。
std::string build_path(const std::string& base, const std::string& name) {
std::string result;
result.reserve(base.length() + 1 + name.length()); // 预留 '/' + '\0'
result = base;
result += '/';
result += name; // 若 name 是右值，此处为移动追加
return result;
}
- 关键点：在首次赋值前调用
reserve，否则result = base已触发一次分配 - 避免
result.append(base).append("/").append(name)—— 链式调用不改变执行逻辑，但可读性差且无性能增益 - 若拼接项数量固定且已知（如 3–5 个），考虑直接用
{s1, s2, s3}.data()构造（C++20std::format更简洁，但非所有环境支持）
编译器和标准库差异会影响结果吗？
会影响。libstdc++（GCC）和 libc++（Clang）对 small string optimization（SSO）的阈值不同（常见 15–22 字节），而 MSVC 的 SSO 行为也略有差异。这意味着：同一段预留 32 字节的代码，在 GCC 下可能免分配，在 MSVC 下仍触发一次堆分配。
立即学习“C++免费学习笔记（深入）”；
- 调试建议：用
std::string::capacity()打印实际分配大小，不要只信reserve参数 - Release 模式下，简单拼接常被编译器内联并优化掉冗余分配；Debug 模式下这些开销更明显
- 跨平台项目慎用「精确预留」，建议预留 1.2–1.5 倍估算长度，留出 SSO 失效余量
reserve 不等于加速，stringstream 不等于通用。拼接前先问自己——数据来源是什么？类型是否混杂？生命周期能否控制？答案不同，选型就该不同。 
