用collections.deque而非列表做双端操作，因其两端操作均为O(1)，而列表头插/头删是O(n)；适用BFS、滑动窗口等场景，不适用高频随机索引访问。
为什么用 collections.deque 而不是列表做双端操作
因为列表（list）在头部插入（insert(0, x)）或弹出（pop(0)）是 O(n) 时间复杂度——每次都要移动后面所有元素；而 deque 底层用双向链表+块状缓冲区实现，两端的 appendleft()、popleft()、append()、pop() 全是 O(1)。
常见错误现象：用 list 模拟队列处理大量实时日志、滑动窗口或 BFS 层序遍历，CPU 突增、响应变慢，却没意识到瓶颈在头尾操作。
- 适用场景：BFS 队列、滑动窗口最大值、撤销/重做栈、生产者-消费者缓冲区
- 不适用场景：需要按索引高频随机访问（如
d[1000]），此时list更快 -
deque的最大长度可设（maxlen=100），超长时自动丢弃对端元素，适合环形缓存
deque 初始化和常用方法怎么写才不出错
初始化时别直接传生成器或大迭代对象——deque(range(10**6)) 会一次性展开并拷贝，内存暴涨；应优先用 maxlen 限制，或分批 extend()。
容易踩的坑：
-
deque([1,2,3])正确；deque(1,2,3)报错：TypeError: expected at most 1 argument -
extendleft()会把序列“倒着”塞入左边：d = deque([1]); d.extendleft([2,3])结果是deque([3,2,1])，不是[2,3,1] -
remove(x)是 O(n)，且只删第一个匹配项；若需高效去重或查找，别依赖它 - 不能用
+=直接拼接另一个deque，得用extend()或extendleft()
在 BFS 和滑动窗口中怎么避免典型性能陷阱
BFS 中最常误用的是把 deque 当普通容器反复 in 判断——if node in queue: 是 O(n)，应配合 set 去重；deque 只负责进出顺序。
滑动窗口（如求最大值）中，有人用 max(d) 实时计算，这又是 O(n)；正确做法是维护单调递减 deque 存下标，每次 popleft() 过期下标、popright() 弹掉小于当前值的旧值。
示例片段（窗口最大值核心逻辑）：
from collections import deque
q = deque() # 存下标，对应值单调递减
for i, x in enumerate(nums):
while q and nums[q[-1]] = k - 1:
result.append(nums[q[0]])
线程安全吗？多线程下要注意什么
deque 的单个方法（如 append()、popleft()）是原子操作，CPython 中线程安全；但复合操作（如先 len(d) > 0 再 d.popleft()）不是原子的，可能引发 IndexError。
真实并发场景下更推荐：
- 用
queue.Queue（内置锁，适合生产者-消费者） - 若坚持用
deque，加threading.Lock包裹读写块 - 避免在多线程中频繁调用
rotate()，它内部有循环移动开销，且非原子
真正难处理的不是两端增删本身，而是边界条件混用（比如 maxlen 触发自动裁剪的同时又在另一线程读取长度）、或把 deque 当作共享状态盲目传递而不加同步——这些地方一出问题就很难复现。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
