当已知最终元素总数且仅用 push_back() 逐个插入时，应使用 reserve() 而非 resize()；reserve() 仅增加容量、不改变 size 也不构造元素，而 resize() 会改变 size 并默认构造所有新元素，可能引发冗余扩容与拷贝。
什么时候该用 reserve() 而不是 resize()
当你只打算往 vector 里逐个插入元素（比如循环调用 push_back()），但**已知最终元素总数**时，reserve() 是唯一正确的选择。它只改容量不改大小，不会构造任何元素；而 resize() 会把新位置填满默认值（比如 int 变成 0），还可能触发一次不必要的扩容——如果当前容量不够，resize(n) 先扩容再初始化，白干一次拷贝。
-
reserve(1000)→size()仍是 0，capacity()≥ 1000，可安全push_back()1000 次不扩容 -
resize(1000)→size()变成 1000，所有元素被默认构造，且若原容量 - 误用
resize()后又用push_back()，可能导致元素数量翻倍（先填了 1000 个 0，再追加新数据）
reserve() 的参数到底该传多大
传太小没用，传太大浪费内存。关键不是“精确”，而是“覆盖最坏情况”。比如读文件行数不确定，但业务上明确不会超过 5000 行，那就 reserve(5000)；如果是网络包解析，单次最多收 64KB 数据，每个元素占 16 字节，那至少预留 64 * 1024 / 16 = 4096 个位置。
- 别用
reserve(vec.size())—— 这毫无意义，当前容量可能已经够了 - 避免
reserve(n + 1)这种试探式调用，它无法阻止后续扩容 - 如果数据来源是另一个容器（如
other_vec），直接reserve(other_vec.size())最稳妥
GCC 和 Clang 的扩容因子差异会影响 reserve() 效果吗
不影响。无论底层用 1.5 倍还是 2 倍扩容，reserve(n) 都会**一次性分配至少 n 个元素的空间**，跳过所有中间扩容步骤。你看到的 “GCC 扩容快、Clang 更省内存” 是指未预分配时的自动行为，一旦调用了 reserve()，这个策略就完全失效了——它直接按需分配，不走倍增逻辑。
- 即使
reserve(1000)后只push_back()10 个元素，容量也维持在 ≥1000，不会缩回去 -
shrink_to_fit()是唯一能尝试释放多余容量的方法，但它不保证成功，且本身要拷贝一次 - 调试时可用
vec.capacity() - vec.size()查看当前冗余空间，比猜更可靠
哪些场景下 reserve() 反而有害
当元素数量极不确定，或平均远小于预估上限时，reserve() 会造成显著内存浪费，尤其在嵌入式、高频服务或内存受限场景。比如一个日志缓冲区，99% 的请求只产生 3 条日志，但你 reserve(1000)，每次都要扛住 1000×sizeof(LogEntry) 的开销。
立即学习“C++免费学习笔记（深入）”；
- 小规模数据（reserve()，现代 CPU 缓存对小内存块很友好
- 频繁创建销毁的短生命周期
vector（如函数局部变量），预分配收益低，反而增加堆压力 - 如果后续会调用
clear()并复用，记得clear()不释放容量，reserve()的效果仍保留
真正容易被忽略的是：预分配不能代替容量检查。如果你在 reserve() 后又用 operator[] 访问未构造的索引（比如 vec[5] = x），程序会崩溃——因为 size() 还是 0，[] 不做边界检查，直接越界写内存。
