Collections.singletonList 返回不可变单元素列表，因底层仅持单引用且所有修改操作均抛 UnsupportedOperationException；适用于只读场景，不支持增删或替换元素。
为什么 Collections.singletonList 返回的列表不能 add/remove
它返回的是一个内部私有静态类 SingletonList，底层直接持有一个 element 引用，没有数组或集合容器。所有修改操作（如 add()、remove()、set()）都直接抛出 UnsupportedOperationException —— 这不是“限制”，而是设计使然：它只承诺「存在且不可变」。
常见错误现象：list.add("x") 立刻崩溃；有人误以为它是「轻量版 ArrayList」，结果在运行时才暴露问题。
- 适用场景：传参给只读接口（如
void process(List）、配置项默认值、测试桩返回单元素集合items) - 不适用场景：需要后续追加元素、批量构建、或需与
ArrayList行为兼容的逻辑 - 注意：它不阻止对元素本身的修改（比如元素是可变对象），只保证集合结构不可变
Collections.singletonList 和 Arrays.asList("x") 选哪个
二者都返回不可修改列表，但行为细节不同：
-
Collections.singletonList("x")：严格单元素，size()永远是1，get(0)安全，get(1)抛IndexOutOfBoundsException -
Arrays.asList("x")：本质是ArrayList的子类封装，支持set(0, ...)（可替换元素），但依然不支持add()/remove() - 性能上无差异，都是 O(1) 创建、O(1) 访问；但
singletonList内存更省（无数组对象开销） - 如果业务语义强调「绝对只有一个、且绝不能被 set 替换」，优先选
singletonList；若只是临时凑个 List 且允许替换首元素，Arrays.asList更直觉
嵌套使用时的坑：Collections.singletonList(null) 是合法的
它允许传入 null，返回的列表 get(0) 就是 null，不会报错。但很多下游代码没做空检查，导致 NPE 出现在别处，排查困难。
- 典型错误现象：
String s = list.get(0).trim()→NullPointerException，但堆栈不指向singletonList调用点 - 建议：除非明确需要表达「存在一个空占位符」，否则避免传
null；可用Optional.empty()或专用空对象替代 - 兼容性注意：Java 9+ 的
List.of("x")不接受null，会直接抛NullPointerException，和singletonList行为不一致
替代方案对比：什么时候该换用 List.of() 或 ImmutableList.of()
Collections.singletonList 是 Java 1.2 就有的老 API，而 List.of()（Java 9+）和 Guava 的 ImmutableList.of() 提供了更统一的不可变集合体验。
-
List.of("x")：语法更简洁，且对空值敏感（拒绝null），适合新项目；但 Java 8 无法使用 -
ImmutableList.of("x")：支持更多构造方式（如copyOf）、提供builder()，调试时 toString 更友好；需引入 Guava - 关键区别：三者都不可修改，但
singletonList是唯一一个「仅承诺单元素」的实现；List.of()和ImmutableList.of()都是通用不可变工厂，单元素只是其特例 - 容易忽略的点：如果你的代码要跑在 Android（旧版本）或某些裁剪 JDK 上，
List.of()可能不可用，此时singletonList反而是最稳妥的跨版本选择
实际用的时候，最常踩的不是语法错，而是把「不可变」当成「元素不可变」，或者在泛型擦除后误判类型安全性——比如往 List extends Number> 里塞 Collections.singletonList(42)，看着没问题，但和通配符协变规则一碰就出意料之外的行为。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
