Python list底层采用约1.125倍的几何扩容策略，即new_size = old_size + old_size // 8 + (old_size < 9 ? 3 : 6)，以摊还O(1)时间复杂度换取空间效率。
Python list 的底层扩容策略是怎么回事
Python 的 list 不是固定大小的数组，而是一个动态数组，内部用 C 语言的指针数组实现。每次 append() 或 insert() 导致容量不足时，解释器会重新分配一块更大的内存，并把旧元素拷贝过去。
关键点在于：扩容不是每次 +1，而是按“增长因子”扩大。CPython 当前（3.9+）使用的是近似 1.125 倍的几何增长（具体公式为 new_size = old_size + old_size // 8 + (old_size ），目的是在空间和时间上做权衡——避免频繁 realloc，也防止过度浪费内存。
常见误解：以为扩容是翻倍。实际在小尺寸时增长更激进（比如从 0→4→8→16），但到一定规模后趋近于 12.5% 增量，比如从 1000 扩到 1125，再扩到 1265……
什么时候会触发扩容？哪些操作不触发
触发扩容的操作只有写入类方法：append()、extend()、insert()（当插入位置超出当前长度）、__setitem__() 对越界索引赋值（如 l[100] = x 且 len(l) ）。
立即学习“Python免费学习笔记（深入）”；
以下操作**不会**触发扩容：
-
pop()、remove()、clear()—— 只减小逻辑长度，不释放底层内存（除非显式调用del或重建） -
__getitem__()、len()、in查找 —— 纯读操作 -
list.copy()或切片l[:]—— 创建新对象，不影响原 list 容量
注意：extend() 如果传入可迭代对象很大，可能一次性触发多次扩容；而预估长度用 [None] * n 初始化再填值，能完全避开运行时扩容。
如何观测和验证当前 list 的实际容量
Python 没有公开 API 直接暴露底层 allocated size，但可通过 sys.getsizeof() 结合已知结构反推，或用 CPython 内部调试手段。更实用的方法是借助 array.array 对比，或使用 gc.get_referents() 配合内存分析工具（如 memory_profiler）。
不过最轻量的实测方式是观察连续 append() 的耗时突变点：
import timeit
l = []
for i in range(10000):
start = timeit.default_timer()
l.append(i)
end = timeit.default_timer()
if end - start > 1e-6: # 粗略捕捉 realloc 耗时尖峰
print(f"size={len(l)-1} -> {len(l)}, took {end-start:.2e}s")
你会发现耗时明显跳升的位置，基本对应底层 realloc 发生的时刻（例如 128→132、512→576 等）。这些数字就是当前扩容阈值的实际体现。
扩容对性能的真实影响有多大
单次扩容本身开销不大（现代 malloc 很快），但问题出在三方面：
-
append()的摊还时间确实是 O(1)，但常数项受内存局部性影响：如果新块不在 CPU 缓存行内，后续遍历变慢 - 频繁扩容会制造内存碎片，尤其在长期运行的服务中，可能引发
malloc分配失败或 GC 压力上升 - 多线程环境下，虽然
list操作本身是原子的，但扩容涉及内存分配，可能成为隐式锁争用点（CPython GIL 不保护 malloc）
真正该警惕的场景是：循环中反复 append() 且无法预估长度（比如解析流式 JSON 数组），此时建议先用 collections.deque 积累，最后转成 list；或用 array.array('i')（类型确定时）减少内存占用与拷贝量。
底层扩容细节随 CPython 版本微调，别硬记倍数，重点理解“它为摊还效率牺牲空间”，并在批量构造时主动绕过它。
