std::string::reserve 和 std::vector::reserve 均只改变 capacity() 不影响 size()，但 string 有 SSO、null 终止符占位、reserve(0) 行为不一致等关键差异，实际行为更复杂且跨平台不可靠。
std::string::reserve 和 std::vector::reserve 都只是改容量，不改大小
行为一致——它们都只调整内部缓冲区的容量（capacity()），不会改变当前元素个数（size()），也不会初始化新增空间。调用后 size() 不变，capacity() 至少达到传入值（可能更大，取决于实现的扩容策略）。
常见错误现象：str.reserve(100); str[50] = 'x'; —— 这是未定义行为，因为 str.size() 还是 0，operator[] 不做越界检查，但访问未构造内存。
- 正确做法：先用
resize()或append()/+=增加有效字符，再用reserve()预留后续空间 -
std::string的reserve()可能触发小字符串优化（SSO）退出，比如从栈内存储切到堆分配；std::vector没这层逻辑，更“直白” - 如果已处于 SSO 状态（如空串或短串），
reserve()可能直接忽略小请求（如reserve(15)），直到超过 SSO 阈值才真正分配堆内存
reserve(0) 在 string 和 vector 中效果不同
这是关键差异点：std::vector::reserve(0) 是合法且无操作（C++11 起明确允许），而 std::string::reserve(0) 在 C++11–C++17 中**可能释放堆内存并退回 SSO 状态**（前提是当前不在 SSO 状态），C++20 起也允许但不保证。
使用场景：想主动“收缩”字符串到栈上存储时，有人误以为 reserve(0) 是标准方式——但它不是可靠手段，shrink_to_fit() 才是语义正确的选择（尽管仍不强制）。
立即学习“C++免费学习笔记（深入）”；
-
vector调用reserve(0)：什么也不做，capacity()保持不变 -
string调用reserve(0)：可能触发 reallocation，也可能没反应，取决于当前是否在堆上、长度是否 ≤ SSO 阈值、编译器实现（libstdc++、libc++ 行为有差别） - 别依赖
reserve(0)做内存管理，它既不是shrink_to_fit()，也不是clear()
reserve 后 push_back / += 的性能表现有隐含差异
对 std::vector，连续 push_back() 在预留足够容量后，一定避免重分配；但 std::string 的 += 或 append() 在某些实现中仍可能额外检查并微调容量（尤其涉及编码/宽字符或自定义 allocator 时）。
常见错误现象：预留了 1000 字节，循环 1000 次 str += "a"，结果发现还是发生了 1–2 次重分配——原因可能是每次 += 内部做了 size() + 1 > capacity() 判断，而字符串末尾的 null 终止符占位让可用空间实际是 capacity() - 1。
-
string的capacity()包含结尾'\\0'的空间，但size()不包含；所以reserve(N)实际最多安全存N-1个字符 - 写循环拼接时，优先用
str.append(buf, len)或str.resize(new_size)+ 手动填充，比反复+=更可控 - libstdc++ 在 debug 模式下会对
string的 capacity 检查更严格，容易暴露这种“差 1”问题
跨平台兼容性：别假设 reserve 会精确分配指定字节数
无论是 string 还是 vector，标准只要求 capacity() >= n，实际分配可能向上对齐（如按 8/16 字节边界）、或乘以增长因子（1.5 或 2）。但 string 还多一层：SSO 阈值是实现定义的（GCC 通常是 15 或 23 字节，MSVC 是 16），这个阈值直接影响 reserve() 是否触发堆分配。
容易踩的坑：在代码里硬写 reserve(1024) 并假设“从此指针稳定”，但在调试版 libc++ 下，它可能分配 1032 字节并对齐到 1040，而 release 版又不一样；更糟的是，如果字符串刚好卡在 SSO 边界附近（比如长度 15），一次 reserve(16) 就可能让行为突变。
- 不要用
data()指针长期缓存，除非你reserve()后再没任何修改操作 - 需要确定内存布局时（如对接 C API），用
std::vector更可预测，std::string的 ABI 和内部结构在不同 STL 实现间差异更大 - 测试时别只看 Linux GCC，macOS（libc++）和 Windows（MSVC）对小字符串处理逻辑不同，reserve 表现可能不一致
字符串的 reserve 看似简单，但混着 SSO、null 终止、编码感知、ABI 差异一起，实际行为比 vector 复杂得多。最稳妥的方式，是把 string::reserve() 当作提示而非承诺，关键路径里宁可多测几个典型长度，也不要靠推理“应该刚好够”。
