Python列表扩容采用几何增长策略，新容量≈当前容量×1.125，摊销时间复杂度O(1)，但会引发偶发延迟与内存浪费。
Python 列表（list）的扩容策略直接影响频繁 append() 操作的性能表现。它不是每次添加一个元素就重新分配内存，而是采用“几何增长”策略——当空间不足时，分配比当前容量更大的新数组，从而摊销单次追加的平均时间复杂度为 O(1)。但这个策略在特定场景下仍会带来可观测的延迟和内存开销。
扩容不是等量增长，而是按比例扩大
CPython 实现中，列表扩容时的新容量计算公式大致为：
- 新容量 = 当前容量 + 当前容量 // 8 + (3 if 当前容量
- 也就是说，容量越大，每次扩大的绝对值越大（例如从 1024 → 1152，再 → 1300+），但增长率逐渐趋近于约 12.5%
- 这种设计平衡了内存浪费与重分配频率：太激进（如翻倍）浪费内存，太保守（如+1）导致频繁拷贝
扩容瞬间会造成明显的延迟尖峰
虽然均摊是 O(1)，但每次扩容需执行三步操作：申请新内存、复制旧元素、释放旧内存。当列表已含数万甚至百万元素时，一次扩容可能耗时毫秒级：
- 例如向一个 50 万元素的 list 追加第 500001 个元素，若触发扩容，需拷贝全部 50 万个对象引用（注意：只复制引用，不深拷贝对象本身）
- 在对延迟敏感的场景（如实时数据采集、高频事件循环）中，这种“偶发卡顿”可能影响响应性
- 可通过
sys.getsizeof(my_list)观察实际分配容量，对比len(my_list)发现冗余空间
预分配可彻底规避动态扩容开销
如果你事先知道最终长度（或上限），用 [None] * n 或 list.__init__() 预分配能完全消除 append 过程中的扩容行为：
立即学习“Python免费学习笔记（深入）”；
-
推荐写法：
result = [None] * expected_size，然后用索引赋值：result[i] = x - 避免写
result = []; for i in range(n): result.append(x)—— 即使 n 固定，也会触发多次扩容 - 若长度不确定但有合理上界，也可先预分配再用
del result[actual_len:]截断
其他常见误判点
有些直觉性理解容易误导优化方向：
- list 扩容不涉及元素内容复制：只复制指针（PyObject*），无论元素是 int、str 还是自定义对象，成本相同
- insert(0, x) 始终是 O(n)：和扩容无关，但会移动所有后续元素，应避免在大列表头部频繁插入
- 小列表（：扩容开销微乎其微，过早优化反而降低代码可读性