该用 Collections.emptyList() 而非 new ArrayList() 时：需返回确定不可修改的空集合，以节省内存、避免意外写操作并利用单例特性；适用于 DTO getter、API 默认响应等场景，不适用于需后续添加元素的临时容器。
什么时候该用 Collections.emptyList() 而不是 new ArrayList()
当你要返回一个「确定不会被修改」的空集合，且希望节省内存、避免意外写操作时，就该用 Collections.emptyList()。它返回的是不可变单例对象，JVM 里只有一份实例，反复调用不新建对象。
常见错误现象：NullPointerException 没有，但后续代码意外调用了 add() 或 clear()，直接抛 UnsupportedOperationException —— 这其实是保护机制在起作用，不是 bug。
- 适合场景：DTO 的 getter 方法、API 响应中字段默认为空集合（如
getRoles()）、工具方法的兜底返回值 - 不适合场景：需要后续往里加元素的临时容器、测试中要 mock 修改行为的对象
- 性能影响：比
new ArrayList()少一次对象分配，GC 压力更小；尤其在高频调用（如循环内）时差异明显
Collections.emptyList() 的类型擦除问题怎么避坑
Java 泛型擦除后，Collections.emptyList() 返回的是 List<object></object>，如果直接赋给 List<string></string> 变量，编译器会警告「unchecked conversion」。
正确做法是显式指定泛型参数，靠编译器推导类型：
立即学习“Java免费学习笔记（深入）”；
return Collections.<String>emptyList();
或者用变量声明引导类型（更常用）：
List<String> roles = Collections.emptyList();
- 别写
(List<string>) Collections.emptyList()</string>—— 强转绕过检查，运行时可能出错 - 在 Java 8+ 中，lambda 或方法引用上下文中，通常能自动推导，但显式写
<T>更稳妥 - IDE（如 IntelliJ）对未标注泛型的
emptyList()会标黄，这不是误报，是提醒你补上类型
和 Arrays.asList()、Lists.newArrayList()（Guava）比有什么区别
Collections.emptyList() 是唯一真正「不可变 + 零长度 + 单例」的组合；其他常见空集合构造方式都不满足全部条件。
-
Arrays.asList()：即使传空数组，返回的也是固定大小、可修改元素（但不能增删）的列表，不是空集合语义 -
Lists.newArrayList()（Guava）：返回的是可变ArrayList实例，每次调用都新建对象，没复用优势 -
ImmutableList.of()（Guava）：功能等价，但引入了第三方依赖；标准库方案更轻量 - 兼容性：从 Java 1.2 就存在，所有 JDK 版本都能用，不用考虑升级成本
为什么不能用 null 代替空集合
因为 null 不是集合，它什么也不是。调用方必须额外判空，否则极易触发 NullPointerException，而且语义模糊——是“没数据”，还是“查失败”，还是“还没初始化”？
- 空集合是明确的业务语义：“有这个字段，但它当前不含任何元素”
- 所有集合操作（
size()、isEmpty()、stream()）可直接调用，无需防御性判空 - 现代 API 设计规范（如 RESTful 响应、Jackson 序列化）都默认把空集合序列化为
[]，而null可能被序列化为null或直接丢弃字段 - Spring Data JPA 等框架的查询方法，约定返回空集合而非
null，违背会导致 NPE 风险上升
最常被忽略的一点：空集合的不可变性不是为了“防止别人改”，而是为了向调用方传递“这个结果不承载状态，你可以放心缓存、复用、甚至共享引用”。一旦用了可变集合，哪怕初始为空，语义就变了。
