未预分配内存时字符串拼接性能断崖式下跌，reserve()可防多次realloc与潜在bad_alloc；需用size_t累加长度并做溢出检查，append时指定长度避免隐式开销。
直接用循环 += 或 append() 拼接大量字符串，不预分配内存，性能会断崖式下跌——这不是慢一点，是可能从毫秒级变成秒级，尤其在日志、协议包、模板渲染等场景下极易触发。
为什么 reserve() 是防溢出的第一道防线
所谓“防溢出”，在这里不是指缓冲区越界（那是 strcpy 的问题），而是防止因反复 realloc 导致的隐式内存耗尽或分配失败。当拼接总长超 10MB 且未 reserve() 时，某些 STL 实现在小容量初始状态下会经历数十次翻倍扩容，每次都要 memcpy 原内容，最后可能因碎片或单次大 alloc 失败而抛 std::bad_alloc。
-
reserve()不改变size()，只确保后续append()在容量足够时不 realloc - 算错总长最多浪费点内存；不算，就大概率触发多次 realloc + 拷贝 + 潜在分配失败
- 对
std::string调用reserve(0)是合法但无意义的；必须传入明确的预估上限
如何安全计算总长度（避免整数溢出）
拼接 100 万次、每次 1KB 的字符串，总长就是 1000000 × 1024 = 1,024,000,000 字节——这已接近 int 上限（2,147,483,647），若用 int 累加中间结果，极易溢出导致 reserve() 传入负数或极小值，后续 append() 立即崩溃。
- 统一用
size_t或uint64_t累加长度，尤其当子串来源含std::string_view::size()、strlen()或用户输入的重复次数时 - 累加前做饱和检查：若当前和 >
SIZE_MAX - next_part.size()，应拒绝拼接或切分任务 - 对固定模式重复（如
"abc"重复n次），直接算static_cast<size_t>(n) * pattern.size()</size_t>，别用int中间变量
append() 参数选错会导致隐式开销翻倍
看似只是写法差异，但在高频拼接中，传错 append() 重载版本会让一次追加多出一次临时 std::string 构造或一次 strlen() 扫描，叠加百万次就是可观延迟。
立即学习“C++免费学习笔记（深入）”；
- 避免
result.append("hello")：编译器虽常优化，但语义上仍要求 null-terminated 扫描 - 改用
result.append("hello", 5)或result.append(std::string_view{"hello"})，长度明确、零扫描 - 若子串来自
std::string& s，优先result.append(s)（移动或引用，不复制）；避免result.append(s.c_str())，它又触发一次strlen - 拼接
char*且长度已知时，绝不要漏掉长度参数——这是最易被忽略的性能开关
超出单次 reserve 容量怎么办
有些场景根本无法预估总长（比如流式解析 JSON 字段名+值拼接），硬要 reserve() 反而导致大块内存长期占用。这时需退到可控扩容策略，而非放任默认行为。
- 不调用
reserve()，但每次append()前检查：if (result.capacity() - result.size() - 避免用
result.reserve(result.size() + add_len)在循环内——它每次只补缺口，等于没 reserve - 极端情况（如日志聚合）可先收集所有
std::string_view到std::vector，再遍历一次算总长，最后一次性reserve+append，比边读边拼更稳
真正难的不是写对一行 reserve()，而是在拼接逻辑分散在多个函数、子模块甚至跨线程时，依然能守住总长估算的完整性与类型一致性——一旦某个环节用 int 接收重复次数，或某处 append(const char*) 替代了带长版本，整个优化链就断了。
