Java中Stack迭代器以FIFO顺序遍历是否为合理设计？

我完全理解你看到Stack迭代器输出FIFO顺序时的惊讶——毕竟Stack的核心定义就是LIFO（后进先出），结果用迭代器遍历居然是先入先出，这确实有点反直觉，甚至会让人怀疑是不是Java的设计出了问题。咱们一步步拆解这个问题：

为什么Stack的迭代器是FIFO顺序？ #

你已经做了不错的调研——答案就是Stack继承自Vector，iterator()方法完全继承自Vector，没有被Stack重写。

Java里的java.util.Stack是JDK1.0就存在的老类，当时为了快速实现栈的功能，直接让它继承了Vector（这样可以复用Vector的底层数组实现和增删改查方法）。而Vector的迭代器是按元素的**插入顺序（也就是底层数组的索引顺序）**遍历的：Stack的push()方法本质上是调用Vector的addElement()，把元素加到数组末尾，所以迭代器从数组头部到尾部遍历，自然就是先插入的元素先被输出（10→20→30→40），也就是FIFO顺序。

而用pop()方法遍历的时候，Stack的pop()是自己实现的，它会从Vector的末尾取出元素（符合LIFO语义），所以输出是40→30→20→10，这才是我们预期的栈顺序。

这种行为是“正确”的吗？ #

从两个维度看：

1. 从现有继承结构的角度：这是符合逻辑的行为——既然Stack继承了Vector，就会继承它的所有非私有方法，包括iterator()。Java的继承机制就是这样，子类会继承父类的实现，除非主动重写。
2. 从Stack的纯粹LIFO语义角度：这确实是一个设计上的“瑕疵”。一个严格意义上的栈，应该只暴露符合LIFO的操作，不应该允许用户以FIFO的方式遍历内部元素。但这是Java早期设计的历史遗留问题——现在回头看，Stack继承Vector本身就是一个设计失误，因为栈和动态数组是完全不同的数据结构，继承关系在这里并不合适（应该用组合而不是继承）。

为什么Java没有重写Stack的iterator()？ #

主要有两个原因：

• 向后兼容性：Stack已经存在几十年了，很多老项目可能已经依赖了这个“意外”的FIFO遍历行为。如果现在突然重写iterator()让它输出LIFO顺序，会导致这些老代码出现bug，Java团队非常重视向后兼容性，不会轻易做这种修改。
• 官方已经不推荐使用Stack了：Java官方文档里明确指出，应该用Deque接口及其实现（比如ArrayDeque）来代替Stack。Deque的设计更合理，它没有继承任何无关的类，而是通过组合实现栈功能：用push()（等价于addFirst()）和pop()（等价于removeFirst()）来严格遵守LIFO，而且Deque的iterator()是按插入顺序遍历，descendingIterator()可以按逆序（也就是栈的弹出顺序）遍历，语义清晰，没有歧义。

总结：现有行为是否“ok”？ #

站在Java的历史包袱和兼容性角度，现有行为是“可以接受”的，但从数据结构的纯粹性来说，确实不够理想。不过现在的最佳实践是彻底放弃使用java.util.Stack，改用Deque实现栈功能，这样就能完全避免这个语义混淆的问题。

举个Deque的例子，既可以按栈的LIFO顺序遍历，也能清晰地控制遍历方式：

Deque<Integer> stack = new ArrayDeque<>();
stack.push(10);
stack.push(20);
stack.push(30);
stack.push(40);

// 按栈的弹出顺序遍历（LIFO）
System.out.println("Deque descendingIterator (LIFO order):");
Iterator<Integer> descIterator = stack.descendingIterator();
while (descIterator.hasNext()) {
    System.out.println(descIterator.next());
}

// 按插入顺序遍历（FIFO）
System.out.println("Deque normal iterator (FIFO order):");
Iterator<Integer> iterator = stack.iterator();
while (iterator.hasNext()) {
    System.out.println(iterator.next());
}

内容来源于stack exchange