Collections.emptyList()不能替代null，因其返回不可变空列表，调用add()/remove()会抛UnsupportedOperationException，难排查且不兼容可变操作与某些泛型约束。
为什么 Collections.emptyList() 不能直接替代 null
它确实返回一个不可变空列表，但关键在于：调用方如果没意识到这是个“合法但只读”的对象，后续调用 add()、remove() 就会抛 UnsupportedOperationException。这不是空指针，但更难排查——尤其当错误发生在深层调用链里时。
常见错误现象：java.lang.UnsupportedOperationException 在你明明只“读”了返回值之后突然冒出；或者测试通过，线上却因某处意外修改而崩。
- 使用场景：适合纯消费型接口（比如
getTags()、getChildren()），调用方只遍历或判断是否为空 - 不适合场景：需要后续添加元素的流程，比如
result.addAll(service.getItems())前没检查可变性 - 参数差异：它返回的是
java.util.Collections$EmptyList，不是ArrayList或LinkedList，类型上不兼容某些泛型约束（如要求List实现类可序列化）
什么时候该用 ImmutableList.of() 而不是 Collections.emptyList()
如果你用的是 Guava，ImmutableList.of() 返回的对象语义更清晰：明确表达“这个空集合就是设计为不可变的”，且类型是具体实现类，调试时更容易识别；而 Collections.emptyList() 的返回类型擦除后容易和普通 List 混淆。
性能影响几乎可以忽略，但兼容性上注意：ImmutableList.of() 在 Java 9+ 可用 List.of() 替代，而 Collections.emptyList() 是 JDK 1.2 就有的，老系统里更稳妥。
- 推荐在新项目中优先用
List.of()（Java 9+）或ImmutableList.of()（Guava），语义强、IDE 提示好 - 如果必须支持 JDK 8 或更低，
Collections.emptyList()仍是安全选择，但得确保文档/命名体现“只读”意图 - 别为了“看起来更现代”强行升级——有些框架（如旧版 MyBatis）对
ImmutableList序列化支持不佳
如何让 IDE 和静态检查帮你拦住误用
IntelliJ 和 SpotBugs 都能识别对 Collections.emptyList() 的非法修改操作，但默认不启用。你需要显式配置。
- IntelliJ：启用
ConstantConditions检查，并在设置里勾选 “Report calls to methods of immutable collections that will always throw” - Maven + SpotBugs：加入
findbugs-maven-plugin，规则包含IMMUTABLE_LIST，它会标出list.add(...)这类调用 - 关键点：这些工具不会报“用了
emptyList不好”，而是报“你正试图改一个明确定义为不可变的东西”——这才是真正要拦的
返回空集合时，比选哪个 API 更重要的是统一契约
团队里有人用 Collections.emptyList()，有人用 new ArrayList()，还有人用 null，调用方就得写三套防御逻辑。这比选错具体方法代价大得多。
最容易被忽略的地方是：空集合的语义可能不等于“无数据”。比如 getUserRoles() 返回空列表，可能是用户真没角色；但 getPendingTasks() 返回空，可能意味着查询失败被静默吞了异常。
- 强制所有集合返回值禁止
null，文档写清“空列表 = 有结果，只是没有元素” - 如果业务上需要区分“查不到”和“查到空”，就别用集合做状态传递，改用
Optional<list>></list>或自定义响应体 - Spring Boot 项目里，考虑全局配置
spring.jackson.deserialization.read-null-as-empty-collection=true，避免前端传null导致后端 NPE
