17370845950

size()表示当前元素个数，capacity()表示已分配内存最多容纳元素数；clear()后size=0但capacity通常不变；reserve()预分配capacity，resize()改变size并可能扩容；shrink_to_fit()仅建议缩容，swap与空vector交换可强制释放内存。

std::vector 的 size() 和 capacity() 到底差在哪

size() 是当前存了多少个元素，capacity() 是底层分配的连续内存能最多装多少个——两者完全独立。比如你 push_back() 10

个 int 后又 clear()，size() 变成 0，但 capacity() 通常不变，内存没还给系统。

扩容时内存怎么分配：不是每次 +1，而是按比例增长

标准不强制具体策略，但所有主流实现（libstdc++、libc++、MSVC STL）都用「倍增」或「1.5 倍」增长。比如容量满时再 push_back()，会新申请一块更大的内存（通常是原 capacity() × 2），把旧数据搬过去，再释放旧内存。

• 这意味着多次 push_back() 的均摊时间复杂度是 O(1)，但单次可能是 O(n)
• 如果你知道最终大概要多少元素，调用 reserve(n) 预分配，能避免多次拷贝和内存碎片
• resize(n) 改的是 size()（必要时也会触发扩容），reserve(n) 只动 capacity()

怎么安全地“真正”释放多余内存

clear() 不释放内存，shrink_to_fit() 才是标准提供的“尽量缩容”请求——但它不保证成功，只是建议实现回收。实际是否释放取决于分配器和当前内存布局。

std::vector v = {1, 2, 3, 4, 5};
v.reserve(100); // capacity=100, size=5
v.clear();       // size=0, capacity 仍为 100
v.shrink_to_fit(); // capacity 可能变成 0 或 5，但不保证

如果必须确保释放，只能手动交换：

std::vector{}.swap(v); // 强制清空并归还所有内存

迭代器失效是内存管理最直接的副作用

只要发生扩容（比如 push_back() 触发重新分配），所有指向该 vector 的迭代器、指针、引用全部失效——因为数据被挪到新地址了。这是使用 vector 时最容易忽略也最危险的一点。

• insert() / erase() 在中间操作只让「被擦除位置及之后」的迭代器失效
• 但 push_back()、resize()、reserve() 这些可能引起重新分配的操作，会让「所有」迭代器失效
• 检查是否要扩容？可以用 v.size() == v.capacity() 提前判断

真正麻烦的不是记不住 capacity 和 size 的区别，而是忘了它们变化时对指针/迭代器的连锁影响——尤其在多线程或回调场景里，一个没留意的 push_back() 就可能让野指针在下一行解引用。