deque比list更适合维护滑动窗口有序性，因其两端操作均为O(1)；求最大值时需维护单调递减双端队列，队首存当前窗口最大值索引，并每次检查其是否过期。
滑动窗口需要维护有序性时，deque比list更合适
因为 deque 的两端插入和删除都是 O(1)，而 list 在头部操作是 O(n)。如果你的滑动窗口逻辑涉及频繁地从左端弹出旧元素、从右端压入新元素（比如求最大值、最小值），直接用 list 会拖慢整体性能，尤其窗口大、数据流长时。
常见错误是把 deque 当作普通队列用，只调用 append() 和 popleft()，却忽略窗口边界外的元素可能仍留在 deque 中——这会导致结果错乱。
- 初始化：用
deque(maxlen=n)只能固定长度但无法支持「条件性剔除」（比如单调队列）；真正滑动窗口一般不用maxlen - 关键动作：每次新元素进来前，先从右端移除违反单调性/过期的元素（如比当前小的数，或索引超出窗口左界的）
- 窗口左边界控制：用索引而非值判断是否过期，避免重复值导致误删
实现单调递减deque求滑动窗口最大值
这是最典型的使用场景：维持一个从左到右递减的 deque，队首始终是当前窗口最大值对应的索引。
容易踩的坑是没在循环里检查队首索引是否已滑出窗口——哪怕 deque 非空，deque[0] 对应的索引也可能 i - k + 1。
立即学习“Python免费学习笔记（深入）”；
from collections import deque
<p>def max_sliding_window(nums, k):
dq = deque()
result = []
for i in range(len(nums)):</p><h1>弹出所有小于当前值的尾部元素（维持递减）</h1><pre class='brush:python;toolbar:false;'> while dq and nums[dq[-1]] < nums[i]:
dq.pop()
dq.append(i)
# 弹出队首过期索引（窗口左边界为 i-k+1）
if dq[0] <= i - k:
dq.popleft()
# 窗口成型后才记录结果
if i >= k - 1:
result.append(nums[dq[0]])
return result用deque做定长窗口的简单统计（如均值、和）
如果只是需要窗口内元素的聚合值（不关心极值或顺序），deque 本身不直接提供 sum/mean，但可配合一个运行变量避免重复计算。
别每次调用 sum(dq) ——那会退化成 O(k) 每步，总复杂度 O(nk)；用增量更新才是 O(1) 每步。
- 初始化时算一次窗口和：
window_sum = sum(nums[:k])，然后初始化dq = deque(nums[:k]) - 滑动时：先
window_sum -= dq.popleft()，再window_sum += new_val，最后dq.append(new_val) - 注意：不能用
dq.appendleft()或反向操作，否则索引和数值对应关系会乱
为什么deque.clear()之后不能再用appendleft()？
这不是 bug，而是 deque 的内部状态残留问题：即使清空了，某些实现下 appendleft() 可能触发未定义行为（尤其在 CPython 3.9 之前）。实际中更稳妥的做法是重建实例。
另一个隐藏问题是多线程场景下，deque 不是线程安全的——如果你在 asyncio 或多线程里共享一个 deque 做窗口缓冲，必须加锁，或者改用 queue.Queue。
真正难处理的从来不是怎么写，而是窗口大小动态变化、数据带时间戳、或需要支持回滚的场景——那种情况下，单纯靠 deque 就不够了，得结合堆或平衡树结构。
