std::string::reserve()比反复+=快得多，因其避免了多次内存重分配与拷贝，将时间复杂度从o(n²)降至o(n)；需预估总长并略留余量，且不可对空字符串调用reserve(0)。
为什么std::string::reserve()比反复+=快得多
因为每次+=可能触发内存重分配和数据拷贝，尤其在拼接大量小字符串时，时间复杂度会退化为 O(n²)。而提前用reserve()一次性申请足够空间，后续所有append()或+=都只是写入，避免了重复分配。
关键点：预估总长度必须略大于实际所需——reserve()不改变size()，只影响capacity()；若预估不足，仍会触发扩容。
- 估算总长 = 所有片段长度之和 + 可能的分隔符长度（如逗号、空格）
- 保守起见可多 reserve 16–64 字节，避免边界对齐导致的隐式扩容
- 不要对空字符串调用
reserve(0)——它不保证后续操作不分配，应至少 reserve(1)
如何用std::string_view避免临时std::string构造开销
如果拼接源是字面量、C 风格字符串或已有std::string的子串，优先用std::string_view传参，避免无谓的堆分配和拷贝。
例如：append()和operator+=都有接受std::string_view的重载（C++17 起），比接受const std::string&的版本更轻量。
- 字面量直接转
std::string_view零成本：sv("hello") - 已有
std::string s取子串：用s.substr(pos, len)返回string_view，而非s.substr(pos, len).c_str() - 注意生命周期：不能把局部
string_view存到容器里，除非确保被引用字符串长期有效
std::ostringstream vs 预分配std::string：什么场景该选哪个
单纯拼接已知类型的字符串片段（如char*、string_view、数字转字符串结果），预分配std::string更快；但若需格式化（如int转带前导零的字符串、浮点数控制精度），std::ostringstream更安全且语义清晰。
不过std::ostringstream默认不支持预分配缓冲区，其内部str()返回的是新构造的std::string，会拷贝全部内容——这不是“极速”路径。
- 追求极致性能：先用
std::to_chars()（C++17）将数字写入预分配的char[]或std::string缓冲区，再append() - 需要格式化又不愿手写转换逻辑：可用
fmt::format_to()（需引入 fmt 库），它支持写入预分配缓冲区 - 避免
oss ——这等于做了两次拷贝
真实拼接循环中容易忽略的三个细节
即使用了reserve()和string_view，循环拼接仍可能掉进坑里。
- 不要在循环内调用
length()或size()来累计长度——编译器未必能优化掉多次调用，建议提前算好总长 - 避免在循环中混合使用
+=和append()：前者可能隐式调用c_str()（对某些实现），后者更直接 - 若拼接对象来自容器（如
vector<string></string>），别用for (auto s : v)——这会拷贝每个string；改用for (const auto& s : v)或for (auto sv : v | views::transform([](const string& x){return string_view(x);}))
预分配本身不难，难的是让每一步都不悄悄触发额外分配或拷贝。最慢的不是reserve()没调用，而是调用了却在别的地方又偷偷 new 了一次。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
