deque比list更适合作队列，因其两端操作均为o(1)，而list的pop(0)/insert(0)为o(n)；适用bfs、滑动窗口等场景，但不适用于高频随机访问；需注意maxlen不可变、extendleft顺序反转、非线程安全及转list开销大等问题。
deque 为什么比 list 做队列更合适
因为 list 在头部执行 pop(0) 或 insert(0, x) 是 O(n) 时间复杂度，每次都要移动后面所有元素；而 deque 的两端操作都是 O(1)，底层是双向链表结构，适合高频入队/出队场景。
常见错误现象：list.pop(0) 在循环中反复调用导致性能骤降，尤其数据量超千条后明显卡顿；有人误以为 list 是“通用队列”，结果在 BFS、滑动窗口等算法里拖慢整个逻辑。
- 适用场景：BFS 层序遍历、任务缓冲池、滑动窗口最大值、撤销操作栈
- 不适用场景：需要按索引随机访问且频繁（
deque[i]是 O(n)，不如list） - 初始化建议统一用
deque()，别传大列表进去——deque([x for x in range(100000)])会一次性拷贝，不如边 append 边构造
常用操作和参数陷阱
deque 支持 append() / appendleft() / pop() / popleft()，但要注意默认行为和可选参数：
-
maxlen是关键参数：设了之后，超出长度时自动从对端挤出旧元素，比如deque(maxlen=3)连续append(1)、append(2)、append(3)、append(4)后只剩deque([2, 3, 4]) - 没设
maxlen时，它无限增长，内存不自动释放——长期运行的服务里忘了限制长度，可能悄悄吃光内存 -
extend()和extendleft()的顺序容易搞反：d.extendleft([1,2,3])实际插入为[3,2,1] + 原内容，因为是从左往左逐个 push
多线程下 deque 不是线程安全的
标准 deque 没有内置锁，多个线程同时调用 append() 和 popleft() 可能引发 IndexError 或数据丢失，这不是概率问题，是必然风险。
立即学习“Python免费学习笔记（深入）”；
- 正确做法：用
queue.Queue替代，它是线程安全的，接口类似（put()/get()），但底层加了锁和条件变量 - 如果坚持用
deque，必须手动加threading.Lock，且锁粒度要覆盖完整操作单元，比如“检查非空 + pop”必须包在一个锁里，拆成两步就可能竞态 -
collections.deque的 C 实现绕过了 GIL 部分操作，但这不等于线程安全——GIL 只保 python 字节码原子性，不保数据结构一致性
从 deque 到 list 的转换成本
需要遍历或序列化时，常写 list(d)，这看似简单，实则暗藏开销：它会新建 list 并逐个复制元素，O(n) 时间 + O(n) 额外内存。
- 如果只是想迭代，直接
for x in d:即可，无需转 list - 如果要用索引查中间元素（比如第 5 个），先确认是否真需要——deque 不适合随机访问；若必须，考虑是否该换数据结构
- 调试打印时写
print(list(d))很方便，但上线代码里避免在热路径上这么干，尤其是大 deque
真正麻烦的是 maxlen 动态调整——一旦设了 maxlen，就不能再改，只能重建新 deque。这点容易被忽略，尤其在配置热更新场景里。