collections.singletonlist 返回不可变单元素列表，因底层仅持单引用且所有修改操作均抛 unsupportedoperationexception；适用于只读场景，不支持增删或替换元素。
为什么 Collections.singletonList 返回的列表不能 add/remove
它返回的是一个内部私有静态类 SingletonList，底层直接持有一个 element 引用，没有数组或集合容器。所有修改操作（如 add()、remove()、set()）都直接抛出 UnsupportedOperationException —— 这不是“限制”，而是设计使然：它只承诺「存在且不可变」。
常见错误现象：list.add("x") 立刻崩溃；有人误以为它是「轻量版 ArrayList」，结果在运行时才暴露问题。
- 适用场景：传参给只读接口（如
void process(List<string> items)</string>）、配置项默认值、测试桩返回单元素集合 - 不适用场景：需要后续追加元素、批量构建、或需与
ArrayList行为兼容的逻辑 - 注意：它不阻止对元素本身的修改（比如元素是可变对象），只保证集合结构不可变
Collections.singletonList 和 Arrays.asList("x") 选哪个
二者都返回不可修改列表，但行为细节不同：
情感家园企业站5.0 多语言多风格版
下载
一套面向小企业用户的企业网站程序！功能简单，操作简单。实现了小企业网站的很多实用的功能，如文章新闻模块、图片展示、产品列表以及小型的下载功能，还同时增加了邮件订阅等相应模块。公告，友情链接等这些通用功能本程序也同样都集成了！同时本程序引入了模块功能，只要在系统默认模板上创建模块，可以在任何一个语言环境（或任意风格）的适当位置进行使用！
-
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 出现在别处，排查困难。
立即学习“Java免费学习笔记（深入）”；
- 典型错误现象：
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)，看着没问题，但和通配符协变规则一碰就出意料之外的行为。 
