std::string::reserve()不能替代拼接时的预分配，因其仅预留容量不改变size，循环中若未预先计算总长度仍会多次重分配；正确做法是先遍历求和再reserve，配合append(iter, iter)批量写入以避免临时对象和隐式转换。
为什么 std::string::reserve() 不能替代拼接时的预分配
直接调用 reserve() 只是预留容量，不改变 size()，后续每次 += 或 append() 仍可能触发多次重分配——尤其在循环拼接中，若未预估总长，reserve() 就成了摆设。
- 典型误用：
s.reserve(100); for (auto& t : vec) s += t;—— 若vec元素总长超 100，仍会扩容 - 正确前提：必须先遍历一次求和所有待拼接字符串的长度，再
reserve() -
reserve()不初始化内存，不会填零；resize()会填充，但通常不需要
用 std::string::append() 配合迭代器批量写入
比反复 += 更高效：避免中间临时对象构造，且 append(first, last) 接口能直接从迭代器范围拷贝，底层常做 memcpy 优化。
- 适用场景：拼接
std::vector<:string></:string>或 C 风格字符串数组 - 示例：
s.append(vec.begin(), vec.end());—— 仅当s已reserve()足够容量才安全 - 注意：
append()不自动扩容，容量不足时行为同+=（抛异常或重分配，取决于实现） - 若源是
const char*数组，先算总长，再reserve()，最后用append(ptr, len)逐段写入
避免隐式转换导致的额外拷贝
传 std::string 值参、用 + 运算符拼接、或对字面量调用 append() 都可能触发不必要的构造/析构。
- 错误写法：
s = s + a + b + c;—— 产生多个临时std::string对象 - 推荐写法：
s.append(a).append(b).append(c);—— 返回引用，链式调用，零额外分配 - 字面量优先用
"hello"sv（C++17std::string_view），避免隐式转std::string - 函数参数尽量用
std::string_view，尤其当只读不修改时
多线程下预分配拼接的陷阱
reserve() 和 append() 都不是线程安全的——即使目标 std::string 是局部变量，若被多个线程共享访问，结果未定义。
- 常见误判：以为“局部变量就线程安全”，忽略了通过引用或指针传递后被并发修改
- 若必须跨线程拼接，要么加锁，要么每个线程各自预分配+拼接，最后由主线程合并
-
std::string的小字符串优化（SSO）在不同 STL 实现中阈值不同（通常 15–22 字节），预分配是否生效需实测验证 - 极端情况：预分配过大（如 GB 级）可能触发 mmap 分配，反而比多次小分配慢
预分配是否真正提速，得看实际数据分布——短字符串多、总数少时，SSO 已足够快；长串批量拼接才值得投入预计算逻辑。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
