deque.peek()返回队首元素但不移除，poll()则移除并返回队首元素；二者配合实现“先预览后消费”的非破坏性预检逻辑，需始终配对使用且先判空再调用。
利用 Deque.peek() 与 poll() 的组合，可以在不提前移除元素的前提下安全预判下一个待处理项，再根据条件决定是否真正消费它——这正是“非破坏性预检”的核心逻辑。
理解 peek() 与 poll() 的关键差异
peek() 只查看队首（或栈顶，取决于 Deque 实现）元素，不改变队列状态；poll() 则取出并移除该元素，返回 null（若为空）。二者配合，相当于“先看一眼，再决定要不要拿走”。
常见误区是误用 remove()（空时抛异常）或混淆双端特性（如用 peekLast() 却配 pollFirst()），需确保操作方向一致。
在数组遍历中模拟“可回退”的扫描逻辑
当遍历数组时，若需基于后续若干元素做决策（如跳过重复、合并区间、识别模式），可将数组索引或元素装入 Deque，用 peek() 预读，用 poll() 确认推进。
- 初始化：把数组所有元素（或索引）依次
addLast()入双端队列 - 循环中：
peek()获取下一个候选值，判断是否满足继续条件（如不等于前一值、未超阈值） - 若满足，再调用
poll()消费它；否则跳过（不 poll），直接进入下一轮
例如去重遍历：while (!deque.isEmpty()) { Integer next = deque.peek(); if (!next.equals(last)) { last = next; result.add(deque.poll()); } else { deque.poll(); } }
避免空指针与状态错位的实操要点
预检必须始终搭配空检查，且 peek 和 poll 应成对出现在同一分支中，防止“看了没拿”导致无限循环或漏处理。
- 永远先
!deque.isEmpty()再调用peek() - 不要在 if 分支外单独调用
peek()后，在 else 中又调用poll()—— 方向可能不一致 - 若需预检多个元素（如 peek 第一和第二个），用
peekFirst()+peekLast()或临时缓存，但注意 poll 仍只影响一端
替代方案对比：为什么不用普通索引或迭代器？
纯索引遍历难以表达“试探性前进”，尤其在嵌套条件或动态步长场景下易写成复杂标记变量；增强 for 循环无法回退或跳步。Deque 提供了显式的、可组合的“看-取”原子语义，语义更清晰，也便于扩展为延迟加载或流式处理。
实际中，若仅需单次预读，也可用变量暂存（如 next = arr[i+1]），但 Deque 在逻辑分层、解耦数据源与消费策略上更具扩展性。
