list.pop(0) 时间复杂度为 O(n)，因需移动后续所有元素；而 deque.popleft() 为均摊 O(1)，适合高频队列操作，性能差距可达百倍以上。
list.pop(0) 为什么慢到不可接受
Python 的 list 底层是动态数组，pop(0) 不只是“删第一个”，而是要把索引 1 到末尾所有元素全部向前移动一位。时间复杂度是 O(n)，不是 O(1)。
当列表有 10 万个元素时，pop(0) 平均要移动 5 万次内存地址；100 万个元素时，平均移动 50 万次——这不是“有点慢”，是每次调用都触发一次大规模内存拷贝。
常见错误现象：
- 在循环里反复
pop(0)模拟队列消费（比如处理日志流、消息队列） - 用
list做 BFS 层序遍历的队列，性能随数据量指数级恶化 - 本地小数据测试正常，上线后吞吐骤降、CPU 持续 100%
deque 是什么，为什么它能 O(1) 删除头部
collections.deque 是双端队列，底层基于双向链表+分块数组（具体是环形缓冲块），支持在头尾都以均摊 O(1) 时间增删。
关键点：
-
deque.popleft()真的是 O(1)，和长度无关 - 不支持按索引随机访问（
d[5]会报TypeError），但如果你在用pop(0)，大概率也不需要随机访问 - 内存占用略高（每个节点带指针开销），但对大多数队列场景可忽略
实操建议：
- 替换只需两步：导入
from collections import deque，把my_list = []改成my_deque = deque()，my_list.pop(0)改成my_deque.popleft() - 如果你原来还用了
append()，它在deque里也叫append()，完全兼容 - 不要试图用
deque做切片或in查找——那是反模式，查存在性请用集合（set）
真实性能差距：10 万次 pop(0) vs popleft()
在主流 Python 3.11 环境下实测（i7-11800H）：
-
list执行 10 万次pop(0)：约 2.3 秒 -
deque执行 10 万次popleft()：约 0.012 秒
→ 差距接近 200 倍
更关键的是增长趋势：
-
list耗时 ≈ O(n²)（因为每轮 pop 都要移动剩余元素） -
deque耗时 ≈ O(n)，线性稳定
如果你的业务逻辑中存在“一边进一边出”的流式处理，且数据规模可能超过几千条，list.pop(0) 就是隐形性能杀手。
什么时候还能忍 list.pop(0)？
仅限以下情况：
- 列表长度始终 ≤ 100，且调用频次极低（比如配置解析一次性操作）
- 你在写教学示例、原型脚本，明确不考虑性能
- 你确认这段代码永远不会被复用或放大（比如单次 CLI 工具，输入固定 3 行）
但只要出现这些信号，就该立刻换 deque：
- 循环体里写了
while my_list:+item = my_list.pop(0) - 日志里看到
time.sleep(0)或asyncio.sleep(0)被用来“让出控制权”，其实是卡在了 pop 上 - profiler 显示
list.pop占 CPU 时间前 3 名
真正容易被忽略的点：很多人以为“我只 pop 几十次，没关系”，却没意识到他们 pop 的列表本身是在一个高频循环里不断 append 进来的——累积效应会让整体延迟不可控。
