结论：collections.deque 是 Python 中唯一真正适合高频双端插入/删除的内置数据结构，比 list 在两端操作上快 10–100 倍，但用错方法或场景反而会拖慢性能；list 的 insert(0,x) 或 pop(0) 为 O(n) 时间复杂度，因需移动所有后续元素，而 deque 基于块状双向链表实现，两端操作均为 O(1)。
直接说结论：collections.deque 是 Python 中唯一真正适合高频双端插入/删除的内置数据结构，比 list 在两端操作上快 10–100 倍，但用错方法或场景反而会拖慢性能。
为什么不能用 list 做双端队列？
list 的 append() 和 pop() 在尾部很快（摊还 O(1)），但 insert(0, x) 或 pop(0) 是 O(n) —— 每次都要移动所有后续元素。实际压测中，10 万次头插，list 耗时约 2.3 秒，deque 只需 0.012 秒。
- 别在循环里对
list频繁调用insert(0, ...)或pop(0) - 如果只是偶尔头插、大部分操作在尾部，
list仍可接受；但一旦涉及「持续双向流动」（比如滑动窗口、BFS 队列），必须换deque -
deque内部是双向链表块（block-based），两端操作都是 O(1)，且 C 实现，无 GIL 争抢瓶颈
deque 初始化和常用操作怎么写才不踩坑？
初始化时传入可迭代对象没问题，但注意：它会把整个对象当作一个元素还是展开成多个元素，取决于你传的是什么。
- 想从列表构建：
deque([1, 2, 3])→deque([1, 2, 3])；但deque([1, 2, 3])和deque((1, 2, 3))效果一致 - 误写成
deque(1, 2, 3)会报TypeError: 'int' object is not iterable - 指定最大长度：
deque(maxlen=5)，满后自动左删右进；但maxlen=None（默认）才能无限增长 -
append()和appendleft()返回None，别链式调用：d.append(1).append(2)会报错
哪些操作会让 deque 性能掉档？
deque 不是为随机访问设计的。虽然支持 d[i]，但时间复杂度是 O(min(i, len(d)-i))，越靠近中间越慢。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
- 避免用
for i in range(len(d)): x = d[i]遍历 —— 改用for x in d:（迭代器是 O(n) 均摊） - 不要用
d.index(x)查找，它是 O(n) 全扫描；若需快速查找，配合set维护索引 -
rotate(n)是高效操作（O(|n|)），但n很大时仍明显卡顿；负数表示左旋，d.rotate(1)相当于d.appendleft(d.pop()) - 切片
d[1:4]返回list，不是deque，且底层要遍历复制 —— 大队列慎用
实际场景：BFS 和滑动窗口怎么写最稳？
BFS 队列和固定窗口维护是 deque 最典型用途，关键点在于「只用两端，不碰中间」。
- BFS：
q = deque([start]); while q: node = q.popleft(); for nei in graph[node]: q.append(nei)—— 严格用popleft()出队、append()入队 - 滑动窗口最大值（单调队列）：
mono = deque(); for i, x in enumerate(nums): while mono and nums[mono[-1]] —— 这里同时用到 <code>append()、pop()、popleft()、[-1]和[0]，全部是 O(1) - 别在 BFS 中混用
list.append()和deque.append()—— 类型不一致会导致逻辑错误，比如if node in q:在deque中是 O(n)，应避免
真正难的不是记住 API，而是判断什么时候该用 deque、什么时候该换结构。比如需要频繁按索引查改中间元素，deque 就不如 list；需要去重+有序，可能得搭配 OrderedDict 或第三方库。边界感比语法更重要。
