应直接使用 Collections.reverse，它原地反转、O(n)时间复杂度、O(1)空间复杂度且经充分测试；手写递归易栈溢出、性能差、易出错，仅限算法题或教学场景。
直接用 Collections.reverse 就够了，别自己写递归
除非你在写算法题或教学演示，否则生产代码里手写递归反转 List 是在给自己埋坑。Java 标准库的 Collections.reverse 是原地操作、时间复杂度 O(n)、空间复杂度 O(1)，且经过充分测试和 JVM 优化。自己递归不仅多占栈空间，还容易触发 StackOverflowError（尤其列表超 5000 元素时）。
常见错误现象：NullPointerException（传入 null）、UnsupportedOperationException（传入不可变集合如 Arrays.asList() 返回的 list）。
- 务必先校验
list != null - 若 list 来自
Arrays.asList()或List.of()，需先转成new ArrayList(list)再调用 - 不要对
LinkedList抱有“它更适合递归”的幻想——Collections.reverse对ArrayList和LinkedList都是统一处理，内部按随机访问能力自动选择策略
Collections.reverse 的真实行为：只改引用，不复制元素
它不是新建一个反序 list，而是直接交换原 list 中元素的引用位置。这意味着：
- 如果你有其他变量也指向同一个 list 实例，它们会“同步看到”反转结果
- 如果 list 里存的是可变对象（比如
new Person("a")），反转不会影响这些对象自身状态，只改变它们在 list 中的顺序 - 性能上无额外对象分配，GC 压力小；但要注意——这同时也是副作用来源，调用前得确认是否允许原地修改
示例：
List<String> names = new ArrayList<>(Arrays.asList("a", "b", "c"));
Collections.reverse(names);
// names 现在是 ["c", "b", "a"]，原对象被修改
递归实现的典型陷阱：边界、泛型、栈溢出
真要写递归（比如面试手撕），最容易翻车的不是逻辑，而是细节：
立即学习“Java免费学习笔记（深入）”；
- 忘记处理空 list 或单元素 list，导致无限递归或数组越界
- 用
list.get(0)和list.subList(1, size)拼接——这会创建新 sublist 视图，每次递归都开销不小，且subList返回的仍是原 backing array，容易引发并发修改异常 - 泛型擦除下，递归方法签名若写成
<t> List<t> reverse(List<t>)</t></t></t>，返回新 list 还行；但若试图原地操作，类型安全难保障 - 对
LinkedList用递归 +removeLast()/addFirst()，看似优雅，实则每次addFirst()都是 O(1)，但整体仍是 O(n²) 时间（因removeLast()在LinkedList是 O(1)，但频繁链表操作仍比数组交换慢）
什么时候该考虑非 Collections.reverse 方案？
只有三种情况值得另起炉灶：
- 你需要一个**不可变副本**（比如不想污染原始 list）→ 用
new ArrayList(list).reverse()，或流式：list.stream().reduce(new ArrayList(), (acc, e) -> { acc.add(0, e); return acc; }, (a, b) -> b)（但注意这个流方案是 O(n²)，仅限小数据） - 你在处理**自定义索引结构**（比如跳表、树形 list），标准 reverse 不适用
- 你正在调试或学习 JVM 栈帧行为，需要观察递归深度 → 此时才应手动写，且务必加 depth 参数限制
其他所有场景，敲 Collections.reverse(list) 就完事。它不炫技，但稳。
最常被忽略的一点：JDK 21+ 的 SequencedCollection 接口新增了 reversed() 方法，返回一个视图（不修改原 list），但它返回的是 SequencedCollection，不是 List，强转会失败——别为了用新 API 而绕开老而稳的 Collections.reverse。
