stack 类继承 vector 违背 is-a 关系、破坏封装性、引入冗余同步开销、方法语义冲突，自 java 6 起被官方建议用 deque（如 arraydeque）替代。

Java 中的 Stack 类继承自 Vector，这一设计在早期 JDK 中看似方便，实则违背了面向对象设计的基本原则，并带来一系列实际缺陷。

违反“is-a”关系，破坏封装性

Stack 并不是一种特殊的 Vector——它不应当拥有随机访问、按索引插入/删除、线程同步等与栈语义无关的能力。继承 Vector 意味着 Stack 不得不暴露所有 Vector 的 public 方法（如 elementAt()、insertElementAt()、removeElementAt()），这严重污染了栈的抽象接口，使使用者可能误用、滥用，破坏 LIFO 原则。

强制继承不必要的同步开销

Vector 的所有 public 方法都是 synchronized 的，而绝大多数栈使用场景并不需要线程安全；更常见的是在单线程中高频调用 push()、pop()。继承导致 Stack 无法摆脱同步锁，性能受损。即使用户明确不需要同步，也无法通过组合等方式绕过该限制。

方法命名与语义不一致

Stack 提供了 push()、pop()、peek() 等符合栈语义的方法，但同时也继承了 Vector 的 add()、remove()、get() 等通用集合方法。例如：

• stack.add(0, x) 会把元素插到栈底，破坏 LIFO 行为
• stack.remove(1) 可能删掉中间元素，使栈结构失效
• stack.get(0) 返回栈底而非栈顶，与 peek() 含义冲突

被官方弃用且无替代增强

自 Java 6 起，Javadoc 明确建议使用 Deque（如 ArrayDeque）替代 Stack；Java 9+ 中 Stack 未被标记为 @Deprecated，但其设计已被视为反模式。值得注意的是：它从未被重构或修复，因为修复需打破向后兼容——只能靠开发者主动规避。

现代写法应直接使用 Deque 接口：用 addFirst()/removeFirst() 或 push()/pop()（ArrayDeque 支持同名方法），既语义清晰，又无同步负担，还能享受更好的缓存局部性和扩容策略。