std::vector::clear() 不释放内存，仅销毁元素并将 size() 归零，capacity() 保持不变；释放内存需用 shrink_to_fit()（仅为请求）或 swap 技巧（强制释放）。
std::vector::clear() 不释放内存
调用 clear() 只会销毁所有元素、把 size() 归零，但底层分配的内存（capacity()）完全保留。这是标准明确规定的——它不涉及任何内存释放操作。
常见错误现象：clear() 后立刻观察内存占用（比如用 top 或诊断工具），发现没变化；或者误以为清空后能立即腾出空间给其他 vector 复用，结果发现 capacity 依然很大。
- 使用场景：频繁复用同一 vector 存储不同批次数据时，
clear()配合预留容量（reserve()）可避免反复分配 - 性能影响：省去 deallocate/allocate 开销，对短生命周期、重复填充的 vector 很友好
- 兼容性无差异：所有符合 C++11 及以上标准的实现行为一致
释放内存得靠 shrink_to_fit()
shrink_to_fit() 是唯一标准提供的、请求释放多余内存的成员函数。但它只是“请求”，不是强制——实现可以忽略，尤其在内存紧张或分配器策略限制时。
典型误用：v.clear(); v.shrink_to_fit(); 写成一行就以为万事大吉，其实第二步可能完全没生效。
立即学习“C++免费学习笔记（深入）”；
- 必须检查效果：调用后对比
v.capacity()和v.size()，若相等才说明成功释放 - 不能替代
swap技巧：C++11 前常用vector<t>().swap(v)</t>强制收缩，现在仍更可靠（尤其对老编译器或嵌入式 STL） - 移动语义下注意：
shrink_to_fit()可能触发元素移动（如果分配新内存并搬数据），要求元素类型可移动
什么时候真需要释放内存？
多数情况下不需要主动 shrink。只有当 vector 长期持有远超当前 size() 的 capacity，且你确认这段内存对整体程序压力显著（比如缓存敏感场景、内存受限环境），才值得干预。
容易踩的坑：在热循环里反复 clear() + shrink_to_fit()，反而因频繁 realloc 拖慢性能；或者为一个只用几次的临时 vector 过度优化。
- 推荐判断依据：看
v.capacity() / v.size()是否持续 > 2～3（空闲容量翻倍以上） - 更安全的写法：
v.erase(v.begin(), v.end()); v.shrink_to_fit();（语义同 clear，但强调“擦除”意图） - 注意异常安全：
shrink_to_fit()可能抛std::bad_alloc（极少，但理论上可能）
手动强制收缩的可靠写法
如果必须确保内存释放（比如调试验证、资源敏感模块），别依赖 shrink_to_fit() 的返回值或文档承诺，直接用 swap 技巧。
std::vector<int>(v).swap(v);
这行代码创建一个临时空 vector（仅含当前 size 个元素的副本），然后和原 vector 交换内部指针——原 vector 的大容量内存随临时对象析构被真正释放。
- 适用所有 C++11+ 标准库，包括 libc++、libstdc++、MSVC STL
- 代价是复制所有元素（O(n) 时间），所以只在确实必要时用
- 注意：若 vector 元素不可拷贝但可移动，改用
std::vector<t>(std::make_move_iterator(v.begin()), std::make_move_iterator(v.end())).swap(v);</t>
clear() 和 shrink_to_fit() 的配合点往往藏在对象生命周期管理边界上——比如一个解析器每次处理完文件就把缓冲 vector 清掉，但下次加载更大文件前，得确保旧内存不卡着不动。这种时候，swap 技巧比寄希望于 shrink_to_fit() 更实在。 
