std::vector::shrink_to_fit不保证释放内存，仅为非绑定提示；常见原因包括分配器忽略请求、SSO机制、容量条件未满足等；强制缩容应使用swap技巧。
std::vector::shrink_to_fit 为什么经常没效果
调用 shrink_to_fit() 后容量没变，不是你代码写错了，而是标准只要求“尽力而为”——它不保证释放内存，底层可能因内存分配器策略（比如避免频繁小块回收）直接忽略请求。GCC libstdc++ 在多数情况下确实不缩容，Clang libc++ 也类似。
- 只对
std::vector有效，std::deque或原生数组不支持 - 触发后实际行为取决于 STL 实现和当前 allocator，无法跨平台预期结果
- 如果刚执行过
clear()，再调shrink_to_fit()，部分实现（如 MSVC）更可能成功
手动缩容：swap 技巧的适用边界
这是目前最可靠、被广泛采用的绕过 shrink_to_fit() 不确定性的办法，原理是构造一个临时 vector 并与原对象交换，强制释放旧内存。
std::vector<int> v = {1,2,3,4,5};
v.resize(2); // 先缩小 size
std::vector<int>(v).swap(v); // 构造临时对象并交换
- 必须先调
resize()或erase()确保v.size()≤ 目标容量，否则 swap 后容量仍很大 - 临时对象的构造会按当前
v.size()分配最小必要内存，swap 后原内存被销毁 - 不适用于自定义 allocator 的 vector（swap 可能失败或未按预期释放）
reserve() 和 capacity() 的常见误解
reserve(n) 是预分配，不是缩容；capacity() 返回的是当前可用空间，不能直接修改。试图通过 reserve(smaller_n) 缩小容量是无效操作——标准规定该调用若新容量小于当前 size，行为未定义；若大于等于 size，则可能扩容，但绝不会缩容。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
v.reserve(10)对已有 capacity=20 的 vector 没影响，也不会降低 capacity - 检查缩容是否生效，应比较
v.capacity()和v.size()，而不是看内存占用工具 - 频繁 resize + shrink_to_fit 或 swap 会带来额外拷贝开销，仅在明确内存受限且 vector 生命周期长时才值得做
原生动态数组（new[]）根本没法安全缩容
C++ 没提供 realloc 的等价物给 new[] 分配的内存。试图用 memcpy 到新数组再 delete[] 旧数组，虽然可行，但需手动管理元素构造/析构，极易出错——尤其对非 POD 类型，漏掉移动构造或析构会导致未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 不要对
std::string、std::vector等含内部资源的对象数组这么做 - 哪怕类型是
int，也要自己跟踪 size/capacity，维护成本远高于直接用std::vector - 唯一“缩容”方式是
delete[]后重新new[]，但这本质是重建，不是原地缩容
真正需要缩容时，优先选 std::vector 配合 swap 技巧；若用裸指针，说明设计已偏离现代 C++ 实践，重构比硬补缩容逻辑更稳妥。
