std::vector().swap(v) 可确定收缩内存，通过交换使原 vector 容量被临时对象带走并析构释放，容量降至约 v.size()；而 shrink_to_fit() 仅为建议，不保证生效。
vector::swap 怎么收缩内存
vector::swap 本身不收缩内存，但配合临时空 vector 使用，能触发移动语义或复制构造的内存重分配，间接实现“收缩”——这是 C++11 之前最常用的手法，现在仍有效，尤其在老标准或需兼容时。
关键在于：swap 后原 vector 的容量被临时对象“带走”，而临时对象析构时释放内存。实际效果等价于“先移动数据，再丢弃旧堆块”。
常见错误是直接调用 v.swap(std::vector 却忽略右值引用支持；C++11 起更推荐用 std::vector，确保临时对象是纯右值，避免意外拷贝。
- 必须写成
std::vector，不能写成().swap(v) v.swap(std::vector（后者可能调用左值重载，不触发收缩）()) - 该操作后
v.size()不变，但v.capacity()会降至最小必要值（通常 ≈v.size()） - 对
std::vector无效（特化实现不同，swap 行为不保证收缩）
为什么 shrink_to_fit 不总生效
shrink_to_fit() 是 C++11 引入的“建议型”接口，标准只要求它“尽量收缩”，不强制立即释放内存。编译器实现可选择忽略——例如 libstdc++（GCC）多数版本中，它内部就是调用 swap 技巧；而 MSVC 的 std::vector 在 debug 模式下常直接返回，不做任何事。
立即学习“C++免费学习笔记（深入）”；
这意味着：依赖 shrink_to_fit() 保内存安全是危险的。若你观察到调用后 capacity() 没变，不是代码写错了，而是实现选择了“暂不响应”。
- 调用后务必检查：
if (v.capacity() > v.size()) { /* 未收缩，需 fallback */ } - 生产环境关键路径中，建议直接用
std::vector替代，行为确定().swap(v) - 注意异常安全：
swap是无异常保证的（noexcept），而shrink_to_fit可能抛bad_alloc（如果尝试重新分配失败）
swap 收缩对迭代器和引用的影响
执行 std::vector 后，所有指向 v 元素的指针、引用、迭代器全部失效——这不是副作用，而是必然结果。因为底层存储已更换（原内存被释放，新内存来自临时对象）。
这点比 shrink_to_fit() 更严格：shrink_to_fit() 若未真正重分配，原有迭代器仍可用；而 swap 技巧一定会换掉内部指针。
- 若代码中持有
&v[0]或v.begin()并后续使用，必须在 swap 前完成读写 - 容器作为类成员时，不要在成员函数中无提示地调用收缩操作，调用方可能正依赖迭代器稳定性
- 多线程环境下，确保 swap 前已完成所有并发读取，否则可能访问已释放内存
移动语义下 swap 的性能差异
C++11 后，std::vector 的移动构造/赋值是 noexcept 且常数时间的（仅交换三个指针）。因此 std::vector 实际开销极小，远低于深拷贝——这也是它至今没被淘汰的核心原因。
但要注意类型 T 的移动是否廉价：若 T 移动构造函数很重（比如含大数组或锁），那整个 swap 过程仍可能慢。此时应优先优化 T 自身，而非回避 swap。
- 对
std::vector<:string>等含动态内存的元素，swap 依然高效（字符串内部也用移动） - 对
std::vector<:array>>这类大栈对象，移动 = 复制，swap 就变成 O(n) 内存拷贝，慎用 - Clang 和 GCC 都会对 trivially movable 类型做额外优化，但不可依赖；实测建议加
-fsanitize=undefined验证移动行为
真正难的是判断“何时必须收缩”——内存碎片、缓存局部性、OOM 风险，三者权重不同。很多所谓“多余内存”，其实是预留的指数增长空间，盲目收缩反而引发频繁 reallocate。先看 capacity() / size() 比值，再结合压测数据决定是否干预。
