capacity()返回已分配但未使用的内存可容纳元素数，size()返回实际元素数；二者不等是因几何扩容预留空间，clear()后capacity不变，reserve(n)仅在n>current capacity时生效。
直接说结论：capacity 是 vector 当前“能装多少”，reserve 是你主动告诉它“我要装这么多，现在就 allocate 好”，两者配合得当，能避免 90% 的隐式扩容开销。
capacity() 返回的是什么，为什么它不等于 size()
capacity() 返回的是当前已分配但尚未使用的内存空间能容纳的元素个数；size() 才是实际有多少个元素。二者差值就是“空着但已付费的房间”。
常见错误现象：
- 打印
vec.size()是 100，vec.capacity()却是 128 —— 这不是 bug，是几何扩容留的余量 - 调用
clear()后size()变 0，但capacity()不变 —— 内存没还，只是清空了内容 - 用
resize(50)缩小容器，capacity()可能不变甚至变大（取决于实现）
reserve(n) 什么时候真正起作用
reserve(n) 只在 n > capacity() 时触发内存重分配；否则什么也不做。它不构造对象、不改变 size()，纯粹是“提前租好整层楼”。
使用场景：
- 已知要 push_back 10 万条日志，先
vec.reserve(100000) - 从文件读取 N 行，且 N 可通过
std::filesystem::file_size()预估 - 函数返回 vector 但内部需多次拼接，入口处统一 reserve
容易踩的坑：
-
reserve(0)或reserve(vec.size())没效果，别白调 - 对空 vector 调用
reserve(1)，capacity 变成 1；但再push_back第二个元素仍会扩容（因 capacity=1，size=1，push_back 触发扩容） - MSVC 和 GCC 的扩容因子不同（1.5 vs 2），跨平台项目别硬编码“刚好够用”的 reserve 值
扩容时到底发生了什么，为什么慢
当 size() == capacity() 且调用 push_back，vector 必须执行三步原子操作：
- 调用 allocator 分配一块新内存（大小 =
max(new_size, current_capacity * growth_factor)） - 逐个移动或拷贝旧元素到新地址（C++11 后优先 move，但要求 move 构造 noexcept）
- 析构旧元素并释放原内存块
性能影响：
- 元素类型越复杂（比如含
std::string成员的类），拷贝/移动成本越高 - 频繁扩容会导致内存碎片，尤其在长期运行的服务中
- 所有指向旧内存的迭代器、指针、引用全部失效 ——
auto it = vec.begin(); vec.reserve(1000); *it是未定义行为
reserve 和 resize 的关键区别不能混用
reserve(n) 改变的是 capacity()，不影响 size()；resize(n) 改变的是 size()，可能顺带改 capacity()（如果 n > 当前 capacity）。
典型误用：
- 想初始化 1000 个默认构造对象，写了
vec.reserve(1000)—— 错，size()还是 0，访问vec[0]崩溃 - 正确做法是
vec.resize(1000)，或vec.reserve(1000); vec.assign(1000, T{}) - 想清空并释放内存？
vec.clear(); vec.shrink_to_fit();—— 注意shrink_to_fit是请求，不保证成功
最易被忽略的一点：reserve 对 vectorcapacity() 和内存布局都不遵循通用规则。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
