vector::clear() 不释放内存，只调用元素析构函数并将 size 设为 0，capacity 保持不变；适用于频繁清空再填充且后续插入规模接近当前 capacity 的场景，不适用于清空后长期闲置或后续插入量极小的情况。
vector::clear() 不释放内存，只清空元素
clear() 的作用是调用每个元素的析构函数，并把 size() 设为 0，但 capacity() 完全不变。底层分配的内存块依然持有，后续 push_back() 可直接复用，避免重新分配。
常见错误现象：反复 clear() 后观察到内存占用没下降，误以为“内存泄漏”；其实只是 vector 缓存了容量。
- 适用场景：需要频繁清空再填充、且预期下次插入规模接近当前
capacity()时，clear()配合复用最高效 - 不适用场景：清空后长期闲置，或后续插入量极小（比如从 10000 个元素清空，之后只加 3 个），此时残留容量浪费明显
- 验证方式：
v.clear(); cout —— 输出值和 clear 前一致
shrink_to_fit() 是非强制的容量缩减请求
shrink_to_fit() 是 C++11 引入的成员函数，语义上是“请求”将 capacity 缩减到当前 size（即最小必要容量）。但它不保证成功 —— 标准只要求“尽力而为”，实际是否释放内存由实现决定（如 libstdc++ 通常会释放，MSVC 旧版本可能忽略）。
典型误用：以为调用一次就一定降内存，结果 capacity() 没变，size() 仍为 0，却没触发 realloc。
立即学习“C++免费学习笔记（深入）”；
- 触发释放的常见条件：当前
size() == 0且底层分配器支持快速回收（多数现代标准库满足） - 更可靠的写法（C++11 起）：
vector—— 创建临时空 vector，与原 vector 交换，原 vector 的内存被临时对象析构时释放().swap(v); - 注意 swap 方式会重置迭代器/引用有效性，且有额外构造/析构开销，别在热循环里滥用
clear + shrink_to_fit 组合也不保险
写成 v.clear(); v.shrink_to_fit(); 看似合理，但依然受制于 shrink_to_fit() 的非强制性。某些编译器或 STL 实现下，这行组合毫无效果。
真正想确保释放：优先用 vector；若需保留部分元素，可先 erase 再 swap 子段，或手动 reserve(0)（但 reserve(0) 不等价于释放，它可能什么都不做）。
-
reserve(n)只影响 capacity 上限，不减少已有容量；reserve(0)在多数实现中无效 - 调试技巧：用
valgrind --tool=massif或 Windows 下的 Process Explorer 观察实际堆内存变化，别只信capacity() - 性能权衡：频繁释放+重新分配比缓存容量更慢，除非明确内存受限（如嵌入式、长时间运行服务）
vector 释放内存的本质是 allocator 行为
vector 自身不管理堆内存，它依赖模板参数 Allocator（默认 std::allocator）。所谓“释放”，其实是调用 allocator 的 deallocate()。而 shrink_to_fit() 是否调用它，取决于 allocator 实现和当前内存布局（比如内存池策略可能延迟释放）。
容易被忽略的一点：即使 capacity() 降为 0，堆内存也未必立即归还给操作系统 —— malloc 实现常把小块内存保留在进程内存池中，供后续 new/malloc 复用。所以用 top 或任务管理器看 RSS 不下降，不等于 vector 没释放。
- 极端情况：大量 vector 占用内存后全部销毁，RSS 仍高 —— 这是 glibc 的 malloc 行为，不是 vector bug
- 若必须交还：可考虑
mallopt(M_TRIM_THRESHOLD, ...)（Linux）或换用 jemalloc/mimalloc 等 allocator - 日常开发中，优先信任 vector 的自动管理，只在 profiling 确认内存瓶颈后才干预
