list.pop(0) 时间复杂度为 O(n),因需移动后续所有元素;而 deque.popleft() 为均摊 O(1),适合高频队列操作,性能差距可达百倍以上。
Python 的 list 底层是动态数组,pop(0) 不只是“删第一个”,而是要把索引 1 到末尾所有元素全部向前移动一位。时间复杂度是 O(n),不是 O(1)。
当列表有 10 万个元素时,pop(0) 平均要移动 5 万次内存地址;100 万个元素时,平均移动 50 万次——这不是“有点慢”,是每次调用都触发一次大规模内存拷贝。
常见错误现象:
pop(0) 模拟队列消费(比如处理日志流、消息队列)list 做 BFS 层序遍历的队列,性能随数据量指数级恶化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)在主流 Python 3.11 环境下实测(i7-11800H):
list 执行 10 万次 pop(0):约 2.3 秒
deque 执行 10 万次 popleft():约 0.012 秒更关键的是增长趋势:
list 耗时 ≈ O(n²)(因为每轮 pop 都要移动剩余元素)deque 耗时 ≈ O(n),线性稳定如果你的业务逻辑中存在“一边进一边出”的流式处理,且数据规模可能超过几千条,list.pop(0) 就是隐形性能杀手。
仅限以下情况:
但只要出现这些信号,就该立刻换 deque:
while my_list: + item = my_list.pop(0)
time.sleep(0) 或 asyncio.sleep(0) 被用来“让出控制权”,其实是卡在了 pop 上list.pop 占 CPU 时间前 3 名真正容易被忽略的点:很多人以为“我只 pop 几十次,没关系”,却没意识到他们 pop 的列表本身是在一个高频循环里不断 append 进来的——累积效应会让整体延迟不可控。