返回空集合而非null是防御性编程的关键实践，能避免NullPointerException、提升可读性与健壮性；应优先使用Collections.emptyList()等不可变单例，而非null或Optional包装。
在业务逻辑中，返回空集合（如 new ArrayList()、Collections.emptyList()）而非 null，是防御性编程的一项关键实践。它能显著减少 NullPointerException，提升代码可读性与调用方的健壮性，避免层层判空带来的冗余和遗漏。
为什么返回 null 容易引发问题
当方法声明返回一个集合类型（如 List<user></user>），但实际可能返回 null 时，调用方必须在每次使用前显式判空：
- 忘记判空 → 运行时抛出
NullPointerException，尤其在链式调用（如service.findUsers().size()）中极易崩溃 - 过度判空 → 每次都写
if (list != null) { ... }，代码臃肿，语义模糊（“null”究竟表示“无数据”、“查询失败”还是“未初始化”？） - API 语义不清 → 调用方无法从方法签名或文档中可靠推断是否可能为
null，增加理解成本和测试负担
空集合比 null 更符合语义与契约
集合类型的本意是“一组元素”，而“零个元素”本身就是合法、明确的状态，完全可用空集合表达：
-
语义清晰：空集合 = “查到了，结果为空”；
null= “没返回任何东西”，含义含糊且易被误用 -
契约友好：方法承诺返回
List<t></t>，就应始终返回一个真实、可用的List实例，而非破坏类型契约的null -
开箱即用：空集合支持所有集合操作 ——
.size()返回 0、.isEmpty()返回 true、可安全遍历（循环体不执行）、可直接参与 Stream 操作，无需额外防护
如何正确返回空集合
优先使用不可变、轻量、线程安全的空集合实例，避免无谓对象创建：
- 对于
List：用Collections.emptyList()（JDK 自带，单例，高效） - 对于
Set：用Collections.emptySet() - 对于
Map：用Collections.emptyMap() - 若需可变集合（如后续要 add），再新建（如
new ArrayList()），但注意评估是否真有必要 - Spring Data JPA 等主流框架默认已遵循此原则（如
repository.findAll()永不返回 null）
配合 Optional 要谨慎
有人误以为“返回 Optional<list>></list>”更安全，实则画蛇添足：
- 集合本身已是容器，再套一层
Optional属于双重包装，增加调用复杂度 -
Optional适用于“值可能存在也可能不存在”的场景（如findById(id)），而“查列表”天然支持“空结果”，无需额外标记“不存在” - 除非业务上需严格区分“查无结果”和“系统异常未返回”，否则不应将空集合包装进
Optional
不复杂但容易忽略：统一约定 + 工具辅助（如 IDE 警告、SpotBugs 规则）能让团队自然养成习惯。空集合不是妥协，而是对类型、契约与协作的尊重。
