应避免使用 java.util.Stack，改用 ArrayDeque 或 LinkedList 实现栈；Queue 是接口，需选用合适实现类；优先使用 offer()/poll()/peek() 而非 add()/remove()/element()；迭代器不保证 LIFO/FIFO 顺序。
Stack 是遗留类，别用 java.util.Stack
Java 的 Stack 类继承自 Vector，底层用同步方法实现线程安全，但代价是性能差、设计过时。它违背了“组合优于继承”的原则——Stack 并不是一种特殊的 Vector，却强行继承，导致暴露了不该有的 add()、removeAt() 等列表操作方法。
实际开发中应改用 Deque 接口的实现类：
-
ArrayDeque：非线程安全，性能最好，推荐作为栈使用（push()/pop()/peek()） -
LinkedList：也可用作栈，但因双向链表结构，随机访问慢，仅在需频繁首尾插入/删除且已引入该类时考虑 - 如需线程安全，用
ConcurrentLinkedDeque或外加Collections.synchronizedDeque()，而非Stack
Queue 接口才是标准队列抽象，实现类分工明确
Queue 是接口，不提供具体实现；真正可用的是它的实现类，各自适用场景差异很大：
-
LinkedList：实现了Queue，支持offer()/poll()/peek()，适合中小规模、非高并发场景 -
ArrayDeque：基于循环数组，无扩容锁争用，比LinkedList更快，且内存更紧凑，是多数情况下的首选 -
PriorityQueue：基于堆，元素按自然序或Comparator排序，poll()返回最小（或自定义优先级最高）元素，不保证 FIFO -
ConcurrentLinkedQueue：无锁、线程安全、非阻塞，适合高并发生产者-消费者模型 -
LinkedBlockingQueue：可选有界/无界，阻塞式，put()/take()会挂起线程，适合需要流控的场景
别混淆 add() 和 offer() 的失败行为
这是初学者最常踩的坑：Queue 接口定义了两套添加方法，语义完全不同：
立即学习“Java免费学习笔记（深入）”；
-
add(E)：成功返回true，失败（如队列满）抛出IllegalStateException -
offer(E)：成功返回true，失败（如容量限制或资源不足）返回false，不抛异常
例如向有界队列 new ArrayBlockingQueue(2) 添加第 3 个元素：
Queue<String> q = new ArrayBlockingQueue<>(2);
q.add("a"); // OK
q.add("b"); // OK
q.add("c"); // 抛出 IllegalStateException: Queue full
而换成 offer() 就不会崩溃：
boolean success = q.offer("c"); // 返回 false，程序继续运行
除非你明确希望失败即中断流程，否则一律优先用 offer()、poll()、peek() 这组方法。
Stack 与 Queue 的迭代器都不反映 LIFO/FIFO 顺序
无论你用 ArrayDeque 当栈还是队列，调用 iterator() 得到的都是从头到尾的顺序遍历结果，不是后进先出，也不是严格按入队顺序（对 PriorityQueue 来说更不是）。
比如：
Deque<Integer> stack = new ArrayDeque<>();
stack.push(1);
stack.push(2);
stack.push(3);
for (int i : stack) {
System.out.print(i + " "); // 输出：3 2 1 —— 这是巧合，依赖于 ArrayDeque 内部结构
}
但注意：这并非规范保证。JDK 文档明确指出 ArrayDeque.iterator() “返回的迭代器不能保证以任何特定顺序遍历元素”。真实项目中若需按栈/队列逻辑遍历，应显式用 while (!stack.isEmpty()) stack.pop() 或收集后反转。
真正容易被忽略的是：没有“安全的、标准的、顺序确定的”遍历方式——必须根据用途手动控制弹出或复制快照。
