shrink_to_fit()只是请求而非保证释放内存，标准允许实现忽略该请求；可靠替代方案是vector(v).swap(v)或v = vector(v)，可强制归还冗余容量。
为什么 vector::shrink_to_fit 不一定释放内存
调用 shrink_to_fit 后发现 capacity() 没变？这不是 bug，而是标准允许的“建议性”行为。C++11 起它只是请求（request）而非保证（guarantee），底层实现可选择忽略——比如 libstdc++（GCC 默认）在多数情况下直接返回，不触发重新分配。
- 常见错误现象：
v.shrink_to_fit(); assert(v.capacity() == v.size());可能断言失败 - 根本原因：避免频繁 realloc 带来的性能抖动，尤其对小容量或短生命周期 vector
- 替代方案本质相同但更可靠：
vector<t>(v).swap(v);</t>或v = vector<t>(v);</t>
手动收缩容量的两种安全写法
当必须确保释放内存（例如处理 GB 级临时数据后防止驻留），绕过 shrink_to_fit 的不确定性：
-
vector<t>(v).swap(v);</t>—— 构造临时 vector（精确容量），再交换，原 vector 的多余内存随临时对象析构释放 -
v = vector<t>(v);</t>—— C++11 后支持移动赋值，效果等价，代码更简洁 - 注意：两者都涉及一次内存分配 + 一次 memcpy，仅在
size() 时值得做 - 不要用
clear()+reserve(0)：前者不清空容量，后者不降低容量
什么时候不该调用 shrink_to_fit
盲目收缩反而损害性能，尤其在以下场景：
- vector 随后会再次增长（如循环中反复 push_back）：收缩后再扩容触发多次 realloc 和拷贝
- 容量只略大于 size（比如
capacity() == size() + 1）：内存浪费可忽略，但调用开销固定 - 使用
std::string且编译器启用了 SSO（短字符串优化）：shrink_to_fit对小字符串无效，甚至可能迫使它脱离栈存储 - 多线程环境频繁访问同一 vector：交换式收缩会短暂使 vector 处于未定义状态，需额外同步
shrink_to_fit 在不同 STL 实现中的表现差异
行为不一致是实际开发中容易踩的坑：
立即学习“C++免费学习笔记（深入）”；
- libc++（Clang 默认）：通常真正释放内存，
capacity()会降至size() - libstdc++（GCC 默认）：多数版本直接 return；GCC 13+ 在部分配置下开始尝试收缩，但仍非强制
- MSVC STL：较新版本（VS2019 16.8+）基本保证收缩，但文档仍标注为“尽力而为”
- 验证方式：
cout "; v.shrink_to_fit(); cout
跨平台项目若依赖收缩行为，必须用交换法，不能假设 shrink_to_fit 有效。
