上一页我们说向量要在内存里连续存放。可问题来了：建向量时得先向系统要一块地，要多大呢？要小了数据装不下，要大了平时又白白空着——这个两难，就是本页的主角。

上页看到静态空间一满就束手无策。生活中房子住不下怎么办？换一套更大的，把家具搬过去，再退掉旧房。向量遇到容量不足时，用的正是这套「换房」策略。

空间不够时，向量按四步完成一次扩容，每步各司其职。

上一页我们看到扩容流程已打通，但还有一个关键决策没定：每次扩多少？搬家太频繁会累，一次搬太大又浪费——增量策略就是在这两者间找平衡。

上一页的递增式扩容每次只多要一点，扩得慢。想想搬家：与其一趟趟搬一个箱子，不如直接换套大一倍的房子——容量翻倍，次数骤减，这就是加倍式扩容。

两者都能自动扩容，但扩多少差一个数量级——这直接决定扩容次数与摊还代价。

一段真实的 C++ expand 实现，看扩容的判断、加倍与搬迁如何落地。

先判断是否真满（多余调用零开销），容量按加倍翻番，再逐元素复制到新空间，最后释放旧区——正是加倍式扩容流程的代码化。

上一页我们看到加倍式扩容看起来最划算。但如果按单次最坏情况算，一次扩容要搬动全部 n 个元素，成本高得吓人——问题出在衡量方式上。

上一页我们看到：只盯单次扩容的最坏代价，会得出「动态数组很慢」的错误结论。更公平的算法是把罕见的大开销摊到之前那些廉价操作上，按平均代价来评估。

从 n 次插入出发，沿两条分支看每次扩容搬多少元素，最后对比总代价与均摊复杂度。

向量采用加倍式扩容，连续追加 n 个元素，为何总耗时是 O(n) 而不是 O(n²)？

• ✓静态容量不足时需动态扩容，容量按需增长
• ✓递增式省内存但摊还 O(√n)，加倍式 O(1)
• ✓扩容虽有开销，摊还后单次操作均摊代价很低
• ✓摊还分析看长期平均，不被单次最坏迷惑
• ✓选策略先问：内存敏感还是操作吞吐优先

先独立想几分钟，再对照参考答案——开放问题没有唯一解。