vector.clear()未释放内存是因为只将size设为0而capacity不变；真正释放需用swap与空vector交换或C++11的shrink_to_fit()（但后者仅为请求）。
vector.clear() 为什么没真正释放内存
clear() 只是把元素个数设为 0，内部缓冲区（capacity()）通常不变。这意味着内存没还给系统，后续 push_back() 还能直接复用——省了重新分配，但也可能长期占着大块闲置内存。
常见错误现象：clear() 后 size() 是 0，但 capacity() 没变，sizeof(vector) 不变，top 或任务管理器里内存占用也没降。
- 适用场景：频繁增删、预期很快会再填满的 vector（比如帧级临时缓存）
- 不适用场景：清空后长期不用，或内存敏感（如嵌入式、长时间运行服务）
- 检查方法：
v.size() == 0 && v.capacity() > 0就说明内存还在
swap + 空临时对象释放内存
这是 C++98/03 时代最通用的“真正释放”手法，利用临时对象生命周期结束时自动析构并释放内存的特性。
实操写法：std::vector<int>(v).swap(v); 或更清晰的两步：std::vector<int>().swap(v);
立即学习“C++免费学习笔记（深入）”；
- 原理：右侧空
vector构造时不分配内存，swap()把原v的缓冲区和空对象交换，原缓冲区随临时对象销毁 - C++11 起可用
v.shrink_to_fit();，但它只是“请求”，实现可忽略；swap是确定性释放 - 注意：
swap后迭代器、指针、引用全部失效，别在 swap 后还拿着旧地址访问
shrink_to_fit() 在不同标准和编译器下的行为差异
shrink_to_fit() 看起来简洁，但实际效果取决于 STL 实现，不能默认它一定起作用。
- libstdc++（GCC）：多数版本会真正释放，但不保证立即归还 OS（可能留着供后续 malloc 复用）
- libc++（Clang）：一般会释放，行为较稳定
- MSVC：从 VS2015 Update 3 起基本可靠，早期版本可能忽略
- 性能影响：触发一次内存释放+可能的重新分配开销，高频调用反而拖慢
建议：仅当代码可读性优先且你确认目标平台 STL 行为可信时用；否则坚持 swap 方案更稳妥。
移动语义下 vector 赋值是否自动释放旧内存
用 v = std::move(other); 后，v 原来的内存会被自动释放——这是移动赋值运算符的标准行为，无需额外操作。
- 但前提是：你没自己写错移动赋值（比如忘了
delete[] data;或漏掉data = nullptr;） - 注意：
std::move本身不释放任何东西，只是转换为右值引用；释放动作发生在operator=内部 - 陷阱：如果
other后续又被使用（比如没置空），可能访问已释放内存，引发未定义行为
真正容易被忽略的是：释放时机依赖于移动赋值的具体实现细节，而 swap 和 clear+swap 是显式、可控、跨平台一致的路径。
