std::string 连续 += 在小规模时并不慢，因SSO和指数扩容使均摊复杂度为O(1)；但大规模（如10⁴次以上）易引发频繁realloc与memcpy，导致性能下降3–5倍，且SSO在单字符串超15–22字节后失效。
用 std::string 连续 += 真的慢吗？
在小规模拼接（比如几十次、每次几字节）时，std::string 的 += 通常不慢——现代 libstdc++ 和 libc++ 都做了 SSO（短字符串优化）和指数扩容，单次追加平均摊还复杂度是 O(1)。但一旦进入“大量”场景（例如循环 10⁴ 次以上拼接长度 2–10 字节的字符串），问题就暴露了：频繁 realloc + memcpy，尤其是当容量反复翻倍又未被复用时，内存碎片和拷贝开销会明显上升。
- 实测常见陷阱：没预估总长，导致扩容 10+ 次，实际耗时比预分配高 3–5 倍
- SSO 失效条件：单个字符串超过 15–22 字节（取决于实现），后续操作全走堆分配
- 别依赖“编译器优化掉临时对象”——
str += a + b + c;中的a + b + c仍会构造临时std::string
std::ostringstream 适合批量拼接吗？
适合，但不是万能解法。std::ostringstream 内部用 std::stringbuf 缓冲，避免了手动管理容量，对混合类型（数字、bool、指针）转字符串特别友好。但它有隐藏成本：格式化逻辑（如 operator 对 int 的进制处理）、locale 查表、以及最终调用 <code>.str() 时的一次完整拷贝。
- 性能关键点：
oss.str()返回新字符串，不移动内部缓冲；C++11 后可用std::move(oss).str()避免拷贝（部分标准库支持，libc++ OK，libstdc++ 7.5+ OK） - 别在循环里反复构造
std::ostringstream——构造/析构流对象本身有开销；应复用对象并调用oss.str({})清空 - 纯 ASCII 字符串拼接时，它比预分配
std::string慢约 1.5–2×；含数字转换时差距缩小甚至反超
预分配 + append() 是最稳的选择吗？
对已知内容长度分布的场景，这是目前综合效率最高、行为最可预测的方式。核心思路：一次 reserve()，之后只用 append() 或 +=，杜绝扩容。
- 估算总长要留余量：比如拼接 1e4 个平均长 5 字节的字符串，reserve(55000) 比 50000 更安全（避免边界处触发最后一次扩容）
- 用
append(const char*, size_t)比+= const char*稍快——后者需先求 strlen，前者跳过 - 如果源数据是
std::string_view（C++17），直接append(sv.data(), sv.size())，零开销 - 注意：GCC 12+ 在
-O2下对连续append()有合并优化，但别依赖——手写 reserve 仍是底线保障
要不要用第三方方案（如 absl::StrCat 或 fmt::format）？
要看你的约束。这些库在“类型安全”和“表达力”上碾压原生方案，但引入依赖和二进制体积增长是真实代价。
立即学习“C++免费学习笔记（深入）”；
-
absl::StrCat：无内存分配（栈上展开参数，写入预分配 buffer），纯 ASCII 拼接比手写reserve+append快 10–20%，但要求所有参数是字面量或string_view；不支持运行时格式化 -
fmt::format：功能等价于 Python 的str.format，支持编译期检查（fmt::format("{:x}", n)），但哪怕最简拼接也比reserve+append慢 2–3×；仅推荐用于需要格式化的混合场景 - 嵌入式或强 ABI 约束项目中，第三方库的符号污染和 STL 版本兼容风险必须提前验证
真正难的不是选哪个 API，而是判断“大量”到底多大量、字符串长度是否稳定、有没有数字转换需求——这些条件一变，最优解就可能从 reserve 切到 ostringstream，甚至退回到 C 风格的 snprintf 手动缓冲。漏掉其中任一维，压测结果就容易失真。
