vector扩容因子非标准强制，GCC/libc++用1.5倍（整数运算：n + n/2），MSVC用2倍；前者省内存但拷贝略多，后者简化逻辑。
vector::push_back 触发扩容时，新容量通常是旧容量的 1.5 倍（GCC）或 2 倍（MSVC）
这不是标准强制要求，C++ 标准只规定 size() ≤ capacity()，且 push_back 平摊时间复杂度为 O(1)。实际增长因子由实现决定：GCC libstdc++ 默认用 1.5 倍（即乘以 3/2），MSVC STL（Visual Studio）用 2 倍。Clang 的 libc++ 行为与 libstdc++ 一致，也倾向 1.5 倍，但具体路径依赖底层整数运算策略。
libstdc++ 中 _S_growth_factor 定义在 bits/stl_vector.h
GCC 源码中，std::vector 扩容逻辑集中在 _Vector_base 和 _M_allocate 调用链里。关键常量是 _S_growth_factor，定义为：
static const float _S_growth_factor = 1.5f;
实际分配时，并非直接乘浮点数，而是用整数技巧避免浮点运算开销：当旧容量为 __n，新容量取 __n + __n / 2（即 __n * 3 / 2 向下取整）。这意味着：
-
capacity=1→ 扩到1 + 0 = 1（不扩，直到第二次 push） -
capacity=2→ 扩到2 + 1 = 3 -
capacity=4→ 扩到4 + 2 = 6 -
capacity=8→ 扩到8 + 4 = 12
这种策略比 2 倍更省内存，尤其对中等规模容器；但频繁重分配时，拷贝次数略多。
MSVC STL 使用 _Grow_to 计算新容量，固定倍增为 2 倍
VS 2019+ 的 STL 源码（如 xmemory）中，_Grow_to 函数逻辑简洁：
return (_Newsize <= _Oldcapacity) ? _Oldcapacity
: (_Newsize <= _Oldcapacity * 2) ? _Oldcapacity * 2
: _Newsize;也就是说，只要所需大小 _Newsize 超过当前 _Oldcapacity，就直接翻倍（除非 _Newsize 已远超两倍，才按需取 _Newsize）。这带来更少的扩容次数，但可能浪费更多内存 —— 比如从 128 扩到 256，即使只新增 1 个元素。
你可以在调试时验证：对空 vector 连续调用 push_back 20 次，在 MSVC 下观察 capacity() 序列为 0,1,2,4,8,16,32,64,128...；而 GCC 下是 0,1,2,3,4,6,9,13,19,28...。
不要依赖具体增长因子，但可通过 reserve() 控制行为
不同编译器、甚至同一编译器不同版本（如 GCC 12 vs GCC 13）都可能微调策略。比如某些嵌入式定制 STL 可能用 1.25 倍来极致控内存。因此：
- 永远别写
if (v.capacity() == v.size() * 2)这类假设性判断 - 若已知最终大小（如读取 N 行文本），优先调用
v.reserve(N)，避免多次拷贝 - 若关注内存碎片或 cache 局部性，可配合
shrink_to_fit()（注意它不保证释放，只是请求） - 自定义分配器无法改变增长因子逻辑，它只接管内存申请
/释放动作
真正影响性能的往往不是“几倍”，而是扩容时是否触发了大量对象的移动构造 —— 尤其对非 trivial 类型，std::vector<:string> 的扩容成本远高于 std::vector。
