c++oding="utf-8" ?>
vector.clear()仅清空元素不释放内存，需用swap与空vector交换或clear后swap才能确定性释放；shrink_to_fit()不保证释放，自定义分配器或移动赋值非必要。
vector.clear() 只清空不释放内存
clear() 会调用每个元素的析构函数，把 size() 设为 0，但底层分配的内存（capacity()）通常保持不变。这意味着内存没还给系统，后续 push_back() 还能直接复用——这在频繁增删场景下是优化，但如果你明确要“彻底释放”，它就不够。
常见错误现象：clear() 后用 malloc_stats() 或任务管理器观察，发现内存没下降；或在内存敏感环境（如嵌入式、长时间运行服务）中反复构造/清空 vector 导致 RSS 持续上涨。
swap with empty vector 是最常用可靠方式
利用移动语义（C++11 起）或拷贝构造的临时对象，把当前 vector 的内部指针和一个空 vector 交换，原内存随临时对象析构自动释放：
std::vector<int> v = {1,2,3,4,5};
v.clear(); // size=0, capacity 仍为5
std::vector<int>{}.swap(v); // v.capacity() == 0，内存已释放</int></int>
等价写法（更直观）：
v.swap(std::vector<int>{});</int>
注意点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
swap是O(1)，无拷贝开销 - C++11 起推荐用
std::vector<t>{}.swap(v)</t>，比vector<t>(v).swap(v)</t>更简洁安全 - 不要写成
v = std::vector<t>{};</t>—— 这会触发赋值运算符，可能做不必要的内存分配再释放
shrink_to_fit() 不保证释放，慎用于“必须释放”场景
shrink_to_fit() 是非绑定请求：标准只要求“尽量减少容量”，实现可忽略。libstdc++（GCC）和 libc++（Clang）通常在 size() == 0 时才真正释放，MSVC 则可能始终不释放。
所以不能依赖它来确保内存归还。实操建议：
- 仅用于“希望优化内存使用但不强求”的场景，比如中间缓存 vector
- 若需确定性释放，必须搭配
clear()+swap，或直接用swap（它本身已隐含 clear） - 调用后检查：
v.capacity()是否为 0 —— 不为 0 就说明没释放成功
自定义分配器或 move 赋值？一般没必要
有人尝试用 std::vector<int myallocator> v;</int> 配合自定义 allocator 控制释放行为，或用 v = std::vector<int>{}</int>。前者增加复杂度且不解决根本问题；后者在 C++11 后虽常被优化为移动赋值，但标准不保证一定触发移动（尤其当 T 移动构造不可用时会退化为拷贝），不如 swap 明确。
真正需要控制内存生命周期的场景（如共享内存、池化），应直接管理原始内存，而不是依赖 vector 的自动行为。
最容易被忽略的一点：即使 swap 成功释放了内存，如果 vector 对象本身是全局或 static 生命周期，其析构函数在程序退出时才调用——此时释放对运行时内存压力无意义，反而可能干扰内存泄漏检测工具。真要控制时机，得确保 vector 是局部对象或显式作用域内销毁。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
