Python collections.deque 的 maxlen 参数在 appendleft/append 时的行为

大家好，我们又见面了啊~本文《Python collections.deque 的 maxlen 参数在 appendleft/append 时的行为》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

maxlen为None时append/appendleft不裁剪元素；为正整数时append右进左出、appendleft左进右出；maxlen=0则静默丢弃所有元素；两者性能差异极小但访问模式影响缓存效率。

maxlen 为 None 时 appendleft/append 不会丢弃元素

当 deque 初始化时传入 maxlen=None（默认值），它就退化为无界双端队列。此时调用 append() 或 appendleft() 永远不会触发自动裁剪，元素只增不减，内存占用随数据线性增长。

常见误判是以为 maxlen=None 等价于“不限制但保留裁剪逻辑”，实际它完全绕过长度检查——源码里对应分支直接跳过 if self->maxlen != Py_None 的判断。

maxlen 为正整数时 append 从右端挤出左端元素

append() 在满容状态下会先执行“右进左出”：新元素追加到右端，同时最左端的元素被 silently 移除。这个行为对 FIFO 场景很自然，但容易忽略它和 appendleft() 的不对称性。

例如：

from collections import deque
d = deque([1, 2, 3], maxlen=3)
d.append(4)  # → deque([2, 3, 4])
d.appendleft(0)  # → deque([0, 2, 3])

关键点：

• append() 挤出的是 d[0]（最旧元素）
• appendleft() 挤出的是 d[-1]（最新加入的右端元素）
• 挤出动作不可逆，没有回调或事件通知

maxlen=0 时所有 append/appendleft 都不存数据

这是最容易被忽略的边界情况：maxlen=0 会让 deque 变成“黑洞队列”——任何 append() 或 appendleft() 都立即丢弃输入，len(d) 始终为 0，且 list(d) 返回空列表。

它不是报错，也不是阻塞，而是静默吞掉一切。适合做占位符或临时丢弃缓冲，但若误设为 0，会导致上游逻辑“以为数据已入队”而实际全丢失。

验证方式：

d = deque(maxlen=0)
d.append(1)
d.appendleft(2)
print(len(d), list(d))  # 输出：0 []

append 和 appendleft 在 maxlen 下的性能差异很小但存在

两者在满容状态下的时间复杂度都是 O(1)，但底层实现略有不同：append() 直接复用右端指针偏移 + 覆盖左端槽位；appendleft() 需要更新左端指针并覆盖右端槽位。实测百万次操作差异在毫秒级，通常可忽略。

真正影响性能的是频繁触发裁剪带来的缓存局部性下降——尤其当 maxlen 很小（如 2~5）又高频增删时，CPU cache line 反复换入换出，比单纯看函数名更值得观察。

如果你在热循环里用 deque 做滑动窗口，优先用 append() + popleft() 组合，它比交替调用 appendleft() 和 pop() 更贴近硬件访问模式。

好了，本文到此结束，带大家了解了《Python collections.deque 的 maxlen 参数在 appendleft/append 时的行为》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！