直接用collections.deque做环形缓冲区需小心maxlen参数，因其仅在显式设置后才启用自动丢弃旧元素的环形语义；未设maxlen则为普通双端队列，不具固定长度特性，且混用pop/remove或非原子判断易引发竞态与逻辑错误。
为什么直接用 collections.deque 做环形缓冲区要小心 maxlen
很多人一想到“固定长度、自动丢弃旧数据”的环形缓冲，立刻选 deque，但默认构造不设 maxlen 就等于普通双端队列，不会自动裁剪。只有显式传入 maxlen 参数，deque 才在 append() 或 appendleft() 时自动弹出对端元素——这才是环形语义的核心机制。
常见错误是先创建空 deque，再手动 pop() 控制长度，这不仅破坏原子性（多线程下易出错），还让逻辑分散、可读性差。
-
deque([], maxlen=5)：初始化即锁定容量，后续所有append()都自动维护环形行为 - 一旦设了
maxlen，就不能再通过append()超过该长度；试图extend()超长列表会截断，但行为不如单次append()可预测 -
maxlen=None（默认）时，deque永远增长，完全不具备环形特性
如何用 deque 实现带索引访问的环形缓冲
原生 deque 不支持 buffer[i] 随机访问，但环形缓冲常需读取“倒数第 N 个”或“从某偏移开始的切片”。这时别硬改底层，用 list(buffer) 转换虽简单，但每次转都 O(n)，高频访问就成瓶颈。
更优解是封装一层，利用 deque 的 rotate() 和只读切片能力：
rotate()
- 只要只用
append()/appendleft()写，maxlen自动管理，就是线程安全的 - 但若混用
pop()、remove()或手动len()判断再操作，就必须加threading.Lock - 避免在信号处理函数（如
signal.signal）中操作deque，因 CPython 的 GIL 在信号中断时可能未完全覆盖
什么场景下不该用 deque 做环形缓冲
当你要做以下事情时，deque 反而添乱：
- 需要低延迟访问中间位置（比如音频处理中每毫秒查 buffer[1024]）→ 用
array.array或numpy.ndarray配合模索引 - 缓冲区大小在运行时动态变化 →
deque的maxlen创建后不可改，只能重建新实例 - 需序列化（如存到文件或网络传输）→
deque本身不可 pickle（虽实际可，但含maxlen时行为易被误读），不如转list再存 - 内存极度受限（嵌入式）→
deque每个节点有指针开销，纯数组更紧凑
环形缓冲真正的复杂点不在“怎么装满再覆盖”，而在于“谁在什么时候读、谁在什么时候写、是否允许读写并发、是否要阻塞等待”。deque 只解决最表层的容器语义，上层协议和同步逻辑得自己兜住。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
