deque.appendleft() 性能远超 list.insert(0, x)，前者 o(1)，后者 o(n)；实测 10⁵ 次插入，deque 仅需 0.02 秒，list 耗时 2.3 秒；频繁头部插入或出队应优先选用 deque。
deque.appendleft() 和 list.insert(0, x) 性能差100倍以上
当你需要在序列头部频繁插入元素时，list.insert(0, x) 会强制把所有已有元素右移一位，时间复杂度是 O(n)；而 deque.appendleft() 只需调整头节点指针，稳定在 O(1)。实测插入 10⁵ 个元素：list 耗时约 2.3 秒，deque 仅约 0.02 秒。
常见错误现象：queue.pop(0) 在 BFS 或任务队列中随数据量增长明显变慢，CPU 占用异常升高，本质就是掉进了这个坑。
- 别用
list.pop(0)做出队 —— 改用deque.popleft() - 如果逻辑上必须“从头取、从尾加”，
deque是唯一合理选择 -
list.insert(0, x)在循环中调用 ≥100 次就该警觉，直接重构为deque
deque 的 maxlen 参数让滑动窗口实现变得原子化
滑动窗口类场景（如最近 N 条日志、实时均值计算）最怕手动维护长度边界。deque(maxlen=N) 初始化后，每次 append() 或 appendleft() 都自动丢弃最老项，无需 if len(d) > N: d.popleft() 这类判断。
这不只是写法简洁的问题：手动切片或条件弹出容易漏删、多删，尤其在并发或异步回调中易引发状态不一致。
-
deque(maxlen=100)是线程安全的单次操作，但整个窗口逻辑仍需外部同步 -
list实现等效逻辑得靠my_list = my_list[-100:]，每次都是O(n)拷贝 - 注意：
maxlen=0会禁用所有添加操作，抛出IndexError，不是“不限长”
deque 不支持高效随机访问，误用反而更慢
d[5] 看似能跑，但底层要从头开始遍历 5 次指针跳转，时间复杂度是 O(n)；而 list[5] 是内存偏移直取，O(1)。一旦你在代码里频繁写 d[i] 或 d[1000:]，说明你其实该用 list。
常见误用场景：把 deque 当作“更快的 list”来存中间结果、做算法题索引查值、或配合 numpy 做向量化——这些都违背设计初衷。
- 需要切片？先转
list(d)[start:end]，别直接d[start:end] - 需要按索引高频读取？换回
list，别硬套deque -
deque.rotate(k)是替代部分切片的高效方式（比如右移 k 位），O(k)比拼接切片快得多
多线程中直接用 deque 是危险的
deque 本身不是线程安全容器。多个线程同时调用 append() 和 popleft() 可能导致 IndexError: pop from empty deque 或数据丢失，这不是概率问题，而是竞态必然结果。
别自己加 threading.Lock 封装——锁粒度难控，且掩盖了选错数据结构的问题。
- 高并发队列场景，请直接用
queue.Queue，它底层已用deque+ 锁封装好 -
asyncio.Queue适用于协程环境，同样基于deque但做了 await 适配 - 若坚持手写线程安全缓冲区，至少确保 lock 包裹的是完整“检查+操作”逻辑，而非只锁单个方法
list 当队列用时那一次次看不见的内存搬移。而 deque 的 maxlen 自动截断、rotate 高效位移、以及对两端操作的无条件 O(1) 保证，都不是语法糖——是必须理解其约束才能释放的硬实力。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
