reserve()只改变capacity不改变size，resize()改变size可能触发reallocation；逐字符push_back未reserve会导致多次realloc和memcpy，性能抖动源于此。
std::string 的 reserve() 和 resize() 到底在动什么内存
扩容性能问题的根源不在字符串内容本身，而在底层缓冲区是否需要重新分配、拷贝。reserve() 只改容量（capacity），不改长度（size）；resize() 会改长度，可能触发 reallocation —— 这才是性能抖动的开关。
常见错误现象：push_back() 逐字符追加时，没预估长度，导致多次倍增式 realloc（如从 1→2→4→8…），每次都要 memcpy 原内容。实测 10 万次 push_back 可能触发 17 次拷贝，而非 1 次。
- 使用场景：读文件行、拼接日志、解析协议字段等「长度可预估」的场合，优先
reserve() - 参数差异：
reserve(n)至少分配 n 字节，但实际分配常向上取整到某对齐值（如 GCC libstdc++ 用 2 的幂，MSVC 用 16 字节对齐） - 注意：
reserve(0)不释放内存（C++11 起标准规定），想清空缓冲得用shrink_to_fit()（但它是非强制的）
不同 STL 实现的扩容因子不是 2
很多人以为 std::string 扩容像 vector 一样固定 ×2，其实不是。这是最容易被源码解读带偏的点：标准只规定“复杂度平均分摊为常数”，没锁死增长策略。
实操建议：别硬记倍数，用 capacity() 观察行为。比如在 Clang + libc++ 下，小字符串（
立即学习“C++免费学习笔记（深入）”；
- GCC libstdc++（glibcxx）：小字符串后首次扩容常为
max(2 * capacity(), capacity() + 16) - MSVC STL：倾向保守增长，常用
capacity() + capacity() / 2（即 ×1.5） - 性能影响：×1.5 比 ×2 更省内存，但多一次 realloc；×2 缓存局部性更好，但可能浪费空间
SSO（短字符串优化）让小字符串完全绕过堆分配
只要字符串长度 ≤ 实现定义的阈值（通常是 15 或 22 字节），std::string 就把字符存在对象内部，不调 malloc。这时候谈“扩容”根本无意义 —— reserve() 无效，capacity() 返回的是 SSO 缓冲大小，不是堆容量。
常见错误现象：写单元测试时用 "hello" 测扩容逻辑，结果发现 capacity() 始终是 15，data() 地址也不变，误以为代码没生效。
- 使用场景：key 字符串（如 map 键）、状态码、固定格式响应体，优先控制在 SSO 阈值内
- 怎么查阈值？
sizeof(std::string)减去指针/size_t 成员大小，剩余空间就是 SSO 容量（含末尾 \0） - 兼容性影响：跨编译器传递
std::string对象（如 DLL 边界）时，SSO 布局不兼容会导致崩溃，必须传 const char*
shrink_to_fit() 不保证释放内存
它只是“请求”收缩，实现可忽略。尤其在某些 libc++ 版本里，即使你刚 clear() 一个大字符串，shrink_to_fit() 也可能什么也不做 —— 因为底层 allocator 认为当前缓冲区还可能复用。
真正想强制释放？目前没标准办法。可行替代：std::string().swap(s)（C++11 前常用），或 C++17 起用 s = {}，依赖 move assignment 的实现逻辑（多数 STL 会触发析构重建）。
- 为什么这样做：避免长生命周期 string 持有大量闲置堆内存，影响整体内存 footprint
- 容易踩的坑：
shrink_to_fit()后立刻data()取地址，可能失效（因缓冲重分配），需重新获取 - 性能代价：哪怕成功 shrink，也要一次 realloc + memcpy，比留着更慢 —— 所以别在热循环里瞎调
SSO 和 allocator 行为都藏在实现细节里，同一份代码在 GCC/Clang/MSVC 下的扩容次数、内存占用、甚至是否 crash 都可能不同。真要压性能，别只看源码注释，得跑 capacity() 日志 + heap profiler。
