deque 的 push_back 和 pop_front 适合滑动窗口因其均为 O(1)；vector 的 pop_front 是 O(n)，易致 TLE；应存下标以准确判断队首是否在窗口内，避免重复值导致误删。
deque 的 push_back 和 pop_front 为什么比 vector 更适合滑动窗口
因为滑动窗口需要频繁在头部删、尾部加，deque 这两个操作都是 O(1)，而 vector 的 pop_front() 是 O(n) —— 它得把后面所有元素往前挪。实际写题时如果误用 vector 模拟，遇到 10⁵ 数据量直接超时。
常见错误现象：vector 配合 erase(begin()) 写滑动窗口，本地小样例过得了，提交后 TLE；或者用 vector + 下标偏移“假装删除”，结果窗口大小维护错，逻辑崩了。
- 只在窗口右边界扩张时用
push_back() - 只在左边界收缩时用
pop_front()，别手抖写成pop_back() - 不要用
deque::at(i)随机访问中间元素——虽然支持，但失去缓存局部性，性能反而不如vector；滑动窗口里你真正需要的只是队首/队尾
单调 deque 维护最大值时，该存下标还是存值
存下标。不是因为“更高级”，而是因为必须靠下标判断队首是否还在当前窗口内。
使用场景：求每个长度为 k 的子数组最大值（经典题 maxSlidingWindow）。如果你存的是值，当队首值重复出现（比如 [3,1,3,2]，k=3），你根本分不清哪个 3 是旧的、哪个是新的，无法安全 pop_front()。
- 入队前 while 循环：只要
nums[deque.back()] 就pop_back()，保持递减 - 出队时机：每次移动左边界前，检查
deque.front() == i - k（即队首下标刚好被踢出窗口），是则pop_front() - 注意比较符号：用
而不是，否则相同值会堆积，导致窗口内最大值“滞留”
clear() 之后 deque 的内存是否释放
不保证。C++ 标准只规定 clear() 清空元素并调用析构，但底层缓冲区通常不归还给系统。这对滑动窗口类高频复用场景是个隐性坑。
性能影响：如果一个 deque 在多轮测试用例中反复 clear() 后又塞入大量元素，它可能一直维持着上一轮的最大容量，浪费内存；极端情况下甚至触发多次内部缓冲区重分配。
- 若需严格控制内存（如嵌入式或长周期服务），改用局部
deque变量，让作用域结束自动销毁 - 避免全局/静态
deque+clear()循环复用 - 真要重用且清空彻底，可声明新对象赋值：
q = deque，多数实现会释放缓冲区();
迭代器失效规则和 for 循环里的常见误用
deque 的迭代器在 push_front()、push_back()、pop_front()、pop_back() 时**不一定失效**（标准允许不失效），但一旦发生内部缓冲区扩容，所有迭代器就全挂了。
最容易踩的坑：边遍历边修改，比如写了个 for (auto it = q.begin(); it != q.end(); ++it)，然后循环体内不小心调了 pop_front() —— 此时 it 可能已悬空，行为未定义。
- 绝对不要在范围 for 循环里调用任何改变 size 的 deque 操作
- 需要边查边删？先记下要删的下标或值，循环结束后统一处理
- 调试时怀疑迭代器问题，加一句
assert(!q.empty());在解引用前，比崩溃后抓瞎强
事情说清了就结束。滑动窗口用 deque 的核心就三点：只动头尾、存下标判有效性、别信迭代器永远安全。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
