std::vector 的 capacity 不等于 size，clear() 不释放内存是因标准要求保留缓冲区以优化性能；swap 临时对象或 c++11 的 shrink_to_fit() 可收缩容量，但后者不保证生效。
std::vector 的 capacity 不等于 size，这是内存不释放的根本原因
很多人发现 clear() 后内存没退给系统，以为“内存泄漏”，其实不是。vector 的 size() 变为 0，但 capacity() 通常不变——底层缓冲区仍被持有，只为后续插入预留空间。C++ 标准明确要求 clear() 不改变 capacity，这是性能优化设计，不是 bug。
用 swap + 空临时 vector 是最通用的 shrink-to-fit 方案
C++11 前没有 shrink_to_fit()，swap 是唯一标准、可移植的释放冗余空间方法。原理是利用临时对象生命周期结束时自动析构并释放内存的特性。
常见写法：
std::vector<int> v = {1,2,3,4,5,6,7,8,9,10};
v.resize(3); // size=3, capacity 仍可能是 10
std::vector<int>(v).swap(v); // ✅ 此时 capacity ≈ size
注意点：
立即学习“C++免费学习笔记（深入）”；
-
std::vector<int>(v)</int>构造临时对象（深拷贝），其 capacity 尽可能紧凑（取决于实现，但通常最小化） -
.swap(v)交换内部指针，原 v 的大缓冲区在临时对象析构时被释放 - 不能写成
v.swap(std::vector<int>(v))</int>—— 临时对象是右值，部分编译器会报错或触发移动语义导致无效交换
C++11 起优先用 shrink_to_fit()，但它不保证一定释放
shrink_to_fit() 是非绑定请求：标准只要求“尽力而为”，实现可忽略。实测中 libstdc++（GCC）通常有效，MSVC 有时延迟释放，libc++（Clang）行为较保守。
安全用法：
- 对内存敏感场景（如长期驻留的大 vector），先调
shrink_to_fit()，再检查capacity()是否下降 - 若未释放，回退到
swap方案 —— 它 100% 有效，且无额外依赖 - 避免在性能关键循环里反复调用，因为涉及内存分配/释放开销
真正要警惕的是隐式增长和迭代器失效引发的意外扩容
很多“内存不释放”问题实际源于反复 push_back() 导致 capacity 指数增长（如 1→2→4→8…），之后即使删掉大部分元素，capacity 仍卡在高位。
预防建议：
- 预估容量时用
reserve(n)，而非依赖自动扩容 - 批量插入前，考虑先
clear()再reserve()，避免旧缓冲残留 - 用
at()替代[]检查越界，防止因异常中断导致清理逻辑跳过 - 注意
erase()返回的是新迭代器，误用旧迭代器可能引发未定义行为，间接影响容器状态判断
swap 技巧看似简单，但必须理解它交换的是指针而非数据；shrink_to_fit 是语法糖，背后没魔法。真正决定内存是否归还系统的，永远是 allocator 的策略和对象生命周期——别让 vector 背锅。
