deque(maxlen=N)是固定长度缓冲区的首选，因其为C实现的双端队列，append/appendleft均为O(1)，满容后自动丢弃最老元素，无需手动pop+append或O(N)切片。
为什么直接用 deque(maxlen=N) 就是固定长度缓冲区
因为 deque 的 maxlen 参数不是“建议长度”，而是硬性截断机制：当插入新元素导致长度超限时，最老的元素会自动被踢出。这省去了手动 pop(0) 或切片维护的逻辑，也避免了 list 在头部删除时的 O(n) 开销。
常见错误是初始化后又调用 appendleft() 或 extendleft() —— 这些操作同样受 maxlen 约束，但容易误以为“从左边加不会触发截断”，其实会从右边挤掉旧元素。
-
deque([1,2,3], maxlen=3)→ 再.append(4)→ 变成deque([2,3,4], maxlen=3) -
deque([1,2,3], maxlen=3)→ 改用.appendleft(0)→ 变成deque([0,1,2], maxlen=3)（3 被挤掉） - 若
maxlen=None，则退化为普通双端队列，无长度限制
什么时候不该用 deque(maxlen=N)
当需要随机访问中间元素且频繁做索引操作（如 d[5]）时，deque 的 O(n) 索引性能会成为瓶颈——它底层是双向链表，不是数组。此时应考虑用 array.array 或 numpy.ndarray 配合模运算手写环形缓冲区。
另一个坑是序列化：含 maxlen 的 deque 被 pickle 保存后恢复，maxlen 信息会保留，但若反序列化环境没有导入 collections，或版本差异大，可能出错。生产中若需持久化，建议显式存 list(d) + maxlen 元数据。
立即学习“Python免费学习笔记（深入）”；
- 不推荐：
json.dumps(deque([1,2,3], maxlen=3))→ 报TypeError（deque不可 JSON 序列化） - 正确做法：
json.dumps({"data": list(d), "maxlen": d.maxlen}) -
maxlen为 0 时，deque拒绝添加任何元素，连初始化都不行，会抛ValueError
deque(maxlen=N) 和手写环形缓冲区的性能差异在哪
对绝大多数场景，deque 的常数级 append/appendleft 已足够快，且代码简洁。它的内部实现做了内存优化，比 Python 层面用 list + index % N 手写更可靠。
但如果你在高频采样（如每毫秒写入）、且缓冲区极大（>100 万元素），deque 的内存碎片可能略高于紧凑的 array.array('d')。这时可测一下：timeit 对比 100 万次 append()，deque 通常快 10%–20%，但内存占用高约 1.5 倍。
- 小缓冲区（deque 是最优解
- 需要保留历史但只读最新 N 个：用
deque；需要按时间戳查某段区间：得换带索引结构的方案 -
deque不支持.remove(x)（会破坏长度稳定性），所以不能用于需动态删中间值的场景
如何安全地把已有 list 转成固定长度缓冲区
别直接 deque(my_list, maxlen=N) —— 如果 len(my_list) > N，它会默默截断前面的元素，而不是报错提醒你数据丢失。应该先校验：
if len(my_list) > N:
raise ValueError(f"Initial data length {len(my_list)} exceeds maxlen {N}")
d = deque(my_list, maxlen=N)更常见的需求是“保留最后 N 个”，此时应显式切片再构造：
d = deque(my_list[-N:], maxlen=N) # 明确意图，避免歧义
- 注意
my_list[-N:]当N > len(my_list)时返回全量，不会报错 - 如果原始数据是生成器（如文件逐行读取），别先转
list再进deque，改用itertools.islice流式取最后 N 行 -
deque构造时传入不可迭代对象（如整数）会报TypeError，错误信息是"'int' object is not iterable"，和预期不符，需提前检查
真正难的不是创建缓冲区，而是确定“固定长度”这个约束是否真的贴合业务——比如网络包重组时，丢弃最老包可能引发协议异常；传感器缓存里截断温度峰值，可能导致告警失效。这些得靠领域逻辑兜底，deque 只负责执行截断。
