应使用Deque接口声明LinkedList栈，仅调用push/pop/peek等栈方法；混用List操作会破坏LIFO语义，且ArrayDeque在多数场景下性能更优、内存更高效。
LinkedList 实现栈时为什么不能直接用 push/pop
Java 的 LinkedList 实现了 Deque 接口，因此自带 push()、pop()、peek() 方法——但这些方法操作的是链表**头部**（即首节点），符合 LIFO 语义。问题在于：如果代码中混用了 add() / removeLast() 等列表式操作，会破坏栈结构的预期行为。
常见错误现象：
- 调用
list.add("a"); list.push("b")后，pop()返回"b"，但get(0)是"a"，索引和栈顶错位 - 用
forEach遍历时顺序与出栈顺序相反，误以为“栈底在前”
正确创建栈语义的 LinkedList 实例
应当明确使用 Deque 类型声明，并只调用双端队列定义的栈方法，避免暴露 List 接口行为：
Deque<String> stack = new LinkedList<>();
stack.push("first");
stack.push("second");
String top = stack.pop(); // "second"
boolean isEmpty = stack.isEmpty(); // true 当栈空
关键点：
立即学习“Java免费学习笔记（深入）”；
- 永远用
Deque接口类型引用，不写LinkedList<string> stack = new LinkedList();</string> - 禁止调用
add(int, E)、get(int)、remove(int)等随机访问方法 -
push(E)等价于addFirst(E)，pop()等价于removeFirst()，性能是 O(1)
与 ArrayDeque 比较：什么情况下不该选 LinkedList 做栈
虽然 LinkedList 支持栈操作，但绝大多数场景下 ArrayDeque 是更优选择：
-
ArrayDeque内存局部性好，扩容策略更可控；LinkedList每个元素额外占用两个指针内存，GC 压力更大 - 当栈深度稳定或可预估（如解析嵌套 JSON、括号匹配），
ArrayDeque的数组结构比链表快 2–3 倍 - 只有在极端场景（如需频繁在栈中间插入/删除，且已确认是瓶颈）才考虑
LinkedList；但此时已不是纯栈语义
错误示范：
LinkedList<Integer> stack = new LinkedList<>(); // 不推荐，即使语法合法
调试栈行为时最容易忽略的陷阱
栈空时调用 pop() 或 peek() 会抛 NoSuchElementException，但这个异常不带上下文信息，容易误判为数据源问题：
- 永远在
pop()前检查isEmpty()，不要依赖 try-catch 捕获来控制流程 -
peek()返回null当且仅当栈为空且元素类型为 nullable（如String），对int等基本类型包装类要小心 NPE - 日志中打印栈状态时，别用
toString()——它输出的是从头到尾的链表顺序，和栈顶到底的逻辑顺序相反
真正需要观察栈顶几个元素时，应手动遍历或转成数组：
Object[] snapshot = stack.toArray(); // 栈顶在 index 0
