collections.deque比list更适合双端操作，因为list头插/头删为O(n)，需移动所有后续元素；deque基于双向链表+块状缓冲区实现，appendleft()、popleft()等两端操作均为O(1)。
为什么 collections.deque 比 list 更适合双端操作？
因为 list 在头部插入（insert(0, x)）或弹出（pop(0)）是 O(n) 时间复杂度，而 deque 的 appendleft()、popleft()、append()、pop() 全是 O(1)。底层用双向链表+内存块混合结构实现，避免了数组整体搬移。
常见误用场景：用 list 做滑动窗口缓存、BFS 队列、撤销栈——这些都该换 deque。
- 初始化时别写
deque([])，直接deque()更轻量 -
deque不支持切片（d[1:3]报TypeError），要用itertools.islice(d, 1, 3) - 如果只做单端操作（比如纯栈或纯队列），
deque依然比list稍快，但差距不大；真正优势在频繁双端混用
deque 的 maxlen 参数怎么用才不踩坑？
maxlen 是唯一能自动丢弃旧元素的机制，但它的行为容易误解：设了 maxlen=3 后，append() 和 appendleft() 会从**对端**挤出元素，不是从同端覆盖。
from collections import deque d = deque(maxlen=3) d.append(1); d.append(2); d.append(3) # [1, 2, 3] d.append(4) # [2, 3, 4] ← 左边1被挤掉 d.appendleft(0) # [0, 2, 3] ← 右边4被挤掉
- 未设
maxlen时，deque可无限增长；设了之后，所有添加操作都受控，但extend()和extendleft()也会触发截断 -
maxlen=None（默认）表示不限长；设为0会导致所有添加操作立即清空队列 - 检查是否满容：不能用
len(d) == d.maxlen判断（maxlen可能为None），稳妥写法是d.maxlen is not None and len(d) == d.maxlen
哪些操作会让 deque 性能骤降？
deque 的随机访问（d[i]）是 O(n) —— 它不是数组，而是链式结构，索引越靠近两端越快，中间最慢。这点和 list 完全相反。
立即学习“Python免费学习笔记（深入）”；
- 避免循环中写
for i in range(len(d)): x = d[i]，改用直接迭代：for x in d: -
index()、count()、remove()全部是 O(n)，且无法加速；如果需要高频查找，考虑额外维护一个set或dict -
rotate(n)看似便宜，但实际是 O(k)，k 是旋转步数；大deque上慎用rotate(10000) - 多线程下，
deque的方法是线程安全的（CPython 实现保证原子性），但复合操作如if d: x = d.popleft()仍需加锁
替代方案：什么时候不该用 deque？
当需求偏离「双端快速增删」这个核心时，deque 反而成了累赘。比如：
- 需要排序 → 用
sorted(d)得到新list，别试图在deque上原地排序 - 要序列化成 JSON →
deque不被支持，得先转list(d)，但大容量时注意内存拷贝开销 - 只做尾部操作且数据量小（list 更省内存，创建更快
- 需要 NumPy 式向量化计算 → 老实用
numpy.array，deque和科学计算生态基本不兼容
最常被忽略的一点：deque 的内存占用比等长 list 高约 2–3 倍，因为每个节点要存前后指针。数据量极大时，得权衡速度与内存。
