Python列表扩容采用过度分配策略以保障append()平均O(1)性能，触发条件为ob_size == allocated，增长公式约为1.125倍，不缩容以避免抖动，extend()因一次预估和分配而显著快于循环append()。
Python列表的扩容不是“刚好够用”，而是刻意多分一点——这种过度分配（over-allocation）是CPython为保障append()平均O(1)性能做的底层妥协，不是bug，是设计。
扩容触发条件：不是“满就扩”，而是len(lst) == allocated
列表对象内部维护两个关键长度：ob_size（当前元素个数，即len(lst)）和allocated（已分配的指针槽数）。只有当ob_size == allocated时，下一次append()才会触发扩容。
- 空列表首次
append()通常从allocated = 0或4起步（版本相关） -
extend()会预估总长度，若预估值 > 当前allocated，直接按需扩容，可能一步到位 -
pop()、del、clear()只减ob_size，绝不缩容——allocated保持不变
增长公式：不是翻倍，而是new_allocated = (size >> 3) + (size
这个C语言位运算表达式等价于：size × 1.125 + 偏移量。它在小列表和大列表间做了平滑过渡：
- 小列表（
size ）：+3，例如从4→8→12→16→20…避免起步太慢 - 中大列表（
size ≥ 9）：+6，再叠加size >> 3（即size // 8），整体≈1.125倍 - 实测序列近似为：
0 → 4 → 8 → 12 → 16 → 20 → 25 → 32 → 39 → 48 → 58 → 72 → 88 → 108…
它比简单翻倍（如2×）更节省内存，又比每次+1快得多；但也不是严格几何级数，属于启发式折中。
立即学习“Python免费学习笔记（深入）”；
为什么不用realloc()缩容？del后内存还在那儿
CPython明确放弃自动缩容——哪怕你把一个百万元素列表clear()掉，sys.getsizeof(lst)几乎不变。
- 缩容要调用
realloc()收缩内存，可能触发物理内存搬移，开销不比扩容小 - 更关键的是：防止“删完立刻再加，又得扩”的抖动（thrashing）
- 真要释放内存，只能重建：
lst[:] = []（原地清空并缩容）或lst = []（弃旧建新）
这点常被忽略：长期复用同一个列表作临时缓冲区，allocated可能远大于当前len()，造成隐蔽内存浪费。
extend()比循环append()快的本质：一次预估，一次分配
当你写for x in data: lst.append(x)，每次append()都要检查ob_size == allocated，可能触发多次扩容+复制；而lst.extend(data)在C层直接遍历data获知长度（支持len()的对象）或边读边估（生成器），然后只做一次容量调整和批量memcpy。
- 对100万个元素，
extend()通常仅扩容1–2次；循环append()可能触发10–20次 - 即使
data是range(10**6)，extend()也能准确预估，不额外加载 - 但若
data是无len()的生成器（如网络流迭代器），extend()无法预估，退化为保守策略，此时分批append()反而可控
过度分配本身不可见，但它决定着你代码在十万级数据下的响应毛刺是否可接受——别只看len()，sys.getsizeof()才是真实内存账本。
