append()不是严格o(1)因单次扩容需o(n)重分配，但均摊为o(1)，因cpython按new_allocated = (size >> 3) + (size
append() 为什么不是严格 O(1)，但能算均摊 O(1)
因为单次
append()可能触发内存重分配，耗时 O(n)，但这种开销被后续多次“免费”追加分摊掉了。CPython 的
list底层是动态指针数组，每次扩容不是+1，而是按公式计算新容量：new_allocated = (size >> 3) + (size 。这意味着：
- 长度为 8 时追加第 9 个元素，容量从 8 扩到 12（+4）
- 长度为 1000 时追加，容量大约增加 125～130 个槽位
- 扩容时必须
memcpy全部旧元素到新地址——这步不可跳过，且是唯一真正 O(n) 的操作- 但之后连续
append()都只改指针和计数，不搬数据所以 10 万次
append()实际只扩容约 15 次，总耗时 ≈ 15 次 O(n) 复制之和，除以 10 万，均摊下来接近常数级。insert(0, x) 为什么永远是 O(n)，没法均摊
insert(0, x)每次都要把全部已有元素往后挪一位，没有缓存、没有预留、没有分摊空间——它每一次都是实打实的 O(n) 搬移。对一个长度为 10 万的列表执行
insert(0, x)，就要复制 10 万个对象引用；执行 1000 次，就是 1000 × 10 万次引用复制，总耗时直接是 O(n²)。这不是“慢一点”，是算法层面的不可优化：底层内存连续，插头就必须整体平移。
Python 3.14.2下载Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
什么时候
append()实际变慢？不是理论问题，是规模问题均摊 O(1) 是理论模型，实际性能受数据规模和使用模式影响明显：
- 循环中追加百万级元素（如日志行、传感器流）时，扩容次数增多，
memcpy累积延迟可测- 对象本身很大（比如含大量属性的自定义类实例），复制引用虽快，但 GC 压力上升，间接拖慢
- 在内存紧张环境（如容器内存限制），频繁 realloc 可能触发系统级内存整理，放大延迟
此时用
collections.deque替代list是更稳的选择——它的append()是真·稳定 O(1)，但代价是my_deque[1000]访问变成 O(n)。别把
insert(len(lst), x)当append()用虽然
lst.insert(len(lst), x)语义上等价于lst.append(x)，但 CPython 并不识别这种模式做优化。它仍会走完整
insert()路径：检查索引、校验范围、调用通用插入逻辑——哪怕只是挪 0 个元素，也多一层函数调用和分支判断。实测中，这种写法比原生
append()慢 10%～20%，且可读性差，容易误导协作者以为你在做特殊位置插入。真正要注意的，从来不是“能不能用”，而是“为什么这里必须用 list 而不是 deque，以及是否真的需要随机访问”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
