应使用 Deque 替代 Stack 实现 LIFO：Stack 是遗留类，继承 Vector 破坏封装、性能差且线程不友好；Deque（如 ArrayDeque）语义清晰、O(1) 高效、编译期安全，符合现代 Java 规范。
用 Deque 替代 Stack 实现后进先出（LIFO）逻辑，核心优势在于更规范、更高效、更安全——Stack 是遗留类，设计上违背了面向对象原则，而 Deque 是 Java 集合框架中专为双端队列设计的接口，其 push()/pop()/peek() 方法语义清晰、性能可控、线程更友好。
避免继承带来的设计缺陷
Stack 继承自 Vector，导致它“既是栈又是向量”，暴露了本不该用于栈操作的方法（如 get(int)、elementAt(int)、removeElementAt(int)）。这破坏了封装性，容易误用。例如，直接调用 stack.get(0) 会取到栈底元素，与 LIFO 意图完全相悖。
- 使用
Deque（如ArrayDeque）可只暴露栈语义方法：仅允许push()、pop()、peek()、isEmpty() - 编译期即限制非法访问，提升代码可读性和可维护性
获得更好的时间复杂度保障
Stack 因继承 Vector，所有方法默认同步（synchronized），带来不必要的性能开销；且 Vector 的扩容机制在栈场景下不够高效（每次翻倍 + 同步锁）。
-
ArrayDeque是非同步实现，push()/pop()均为 O(1) 均摊时间复杂度，无锁开销 - 底层基于循环数组，空间利用率高，比链表实现（如
LinkedList作为Deque）缓存局部性更好 - 若需线程安全，可显式包装为
Collections.synchronizedDeque()，职责更清晰
符合现代 Java 集合规范与演进方向
Stack 自 Java 1.0 存在，但官方文档早已明确标注为“legacy class”，不推荐新代码使用；而 Deque 自 Java 6 引入，是集合框架中正式支持栈语义的标准方式。
-
Deque接口定义了统一的栈操作命名（push/pop/peek），语义比Stack的push/pop/peek更一致（Stack的pop会抛异常，peek不抛，行为边界模糊） - 主流 IDE 和静态分析工具（如 IntelliJ、SonarQube）会对
Stack用法发出警告，提示迁移到Deque - Spring、Guava 等主流库内部栈逻辑均基于
Deque，保持技术栈一致性
迁移成本低，API 几乎无缝对接
将 Stack<E> 替换为 Deque<E> 只需少量改动，且行为完全兼容：
- 原
new Stack<>()→ 改为new ArrayDeque<>() -
stack.push(e)、stack.pop()、stack.peek()可直接保留（Deque接口已定义同名方法） -
stack.empty()→ 改为deque.isEmpty()（更符合集合命名习惯） - 注意：
Stack的search(Object)是非标准栈操作，若业务强依赖，需自行实现或改用其他结构
