直接用+拼接字符串慢是因为每次操作可能触发内存重分配和拷贝，循环中导致o(n²)复杂度；通过reserve()预分配空间可避免频繁扩容，提升性能。
为什么直接用 + 拼接字符串会慢？
因为每次 + 或 += 都可能触发内存重新分配和数据拷贝。尤其在循环中拼接大量小字符串时，std::string 的容量（capacity()）若未提前预留，会按指数增长策略反复 realloc，导致 O(n²) 时间复杂度。
用 reserve() 预分配足够空间
先估算最终长度，调用 reserve() 一次性分配内存，后续拼接就基本避免扩容。关键点是：它只影响容量，不改变当前长度（size()），也不初始化内存。
- 估算不准也没关系——只要不低于实际需求，就不会二次扩容；多预分配一点，比频繁 realloc 更划算
-
reserve()不是线程安全的，多线程写同一string仍需同步 - 如果后续调用
clear()，容量保留；但erase()后容量不变，shrink_to_fit()才能释放冗余内存
示例：
std::string result;
result.reserve(1024); // 预估总长，比如 1KB
for (const auto& s : string_vec) {
result += s; // 此处不再分配，仅复制数据
}
避免隐式临时对象：优先用 append() 而非 +
str += s 和 str.append(s) 效果相同，但 str + s + t 会产生多个临时 string 对象，每个都涉及构造+析构+内存操作。
- 循环内永远用
+=或append()，不用+连接多个右值 -
append()有多个重载，比如append(const char*, size_t)可避免构造临时std::string，对 C 风格字符串尤其高效 - 若拼接的是字面量（如
"key:" + value），编译器可能优化，但不可依赖；稳妥起见仍用append()或+=
注意 std::string_view 不能直接 reserve
std::string_view 是只读视图，没有内存管理能力。想用它加速拼接，必须先转成 std::string 再 reserve()。常见错误是误以为 string_view 可以替代 string 来拼接：
// ❌ 错误：string_view 没有 reserve() std::string_view sv = "hello"; sv.reserve(10); // 编译失败 // ✅ 正确：先构造 string，再 reserve std::string s(sv); s.reserve(sv.size() + 100);
真正省时间的地方不在视图本身，而在避免构造中间 string ——所以拼接前尽量用 string_view 接收参数，再统一 append 到已 reserve 的目标串里。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
