shrink_to_fit不保证释放内存，仅请求减少容量；真正释放需用swap技巧：std::vector(v).swap(v)；适用场景为长生命周期容器经历“插入→删除→只读”且经profiler确认内存瓶颈。
shrink_to_fit 不保证释放内存，它只是请求
shrink_to_fit() 是 C++11 引入的非绑定操作：标准只要求它“尽可能减少容量”，但不强制编译器立刻归还内存给系统。实际行为取决于 STL 实现（如 libstdc++、libc++、MSVC STL）和当前内存分配策略。
常见现象是调用后 capacity() 没变，size() 也没变，看起来完全没效果——这不一定是 bug，而是实现选择了“暂不释放”。
根本原因是：多数分配器（如 malloc 包装器）在释放小块内存时并不立即交还给 OS，而是保留在进程堆中供后续复用，以避免频繁系统调用开销。
想真正释放内存？得配合 swap 技巧
唯一跨平台、可预期释放多余内存的方法是利用 vector 移动语义 + 临时对象：
std::vector<int> v = {/* 大量元素 */};
v.erase(v.begin() + 100, v.end()); // 现在 size 小了，但 capacity 可能仍很大
std::vector<int>(v).swap(v); // 关键：构造临时 vector 并交换这个技巧生效原理：
• 临时 std::vector<int>(v)</int> 按 v.size() 分配最小必要空间
• swap() 交换两个 vector 的内部指针（O(1)，无拷贝）
• 临时对象析构，其原 capacity 对应的大块内存被真正释放
注意：C++11 起支持移动构造，该写法安全；若用 C++98，则需用 std::vector<int>(v).swap(v)</int> 的等价形式（如 copy + assign）
使用场景要明确：不是所有情况都值得 shrink
盲目调用 shrink_to_fit() 或 swap 技巧反而有害：
立即学习“C++免费学习笔记（深入）”；
- 后续还会往 vector 中 push_back —— 再次扩容会触发新内存分配+数据拷贝，得不偿失
- vector 生命周期短（比如函数局部变量），函数返回即销毁，无需手动干预
- 内存压力来自其他模块（如图像缓存、网络 buffer），vector 占比微乎其微，优化意义不大
- 多线程环境里，频繁 resize/shrink 可能加剧内存碎片或锁争用（尤其在 jemalloc/tcmalloc 下）
真正适合的场景：长生命周期容器、明确经历“大量插入 → 大量删除 → 长期只读”阶段，且经 profiler 确认其 capacity 显著高于 size 并构成内存瓶颈。
libstdc++ 和 MSVC STL 的实际表现差异
不同标准库对 shrink_to_fit() 的实现激进程度不同：
- libstdc++（GCC）：多数版本下
shrink_to_fit()直接等价于swap技巧，会立即释放（除非分配器阻止） - libc++（Clang）：更保守，常只调整内部 bookkeeping，不触发
deallocate - MSVC STL（Visual Studio）：2015 及以后版本在 debug 模式下可能忽略请求；release 模式下行为接近 libstdc++
因此，依赖 shrink_to_fit() 的可移植代码必须做 fallback：先调用，再检查 capacity() == size()，不满足则手动走 swap 路径。别假设一次调用就万事大吉。
