应使用 collections.emptylist() 替代 null 返回空集合，因其不可变、泛型安全、线程安全且内存开销小；null 易引发 nullpointerexception 并增加判空负担，而 optional 更适用于单个对象而非集合。
用 Collections.emptyList() 替代 null 作为空集合的返回值，是一种被广泛推荐的防御性编程实践。它能避免调用方频繁判空、减少 NullPointerException 风险，并让 API 更加语义清晰、行为可预测。
为什么不该返回 null 表示“无数据”
返回 null 要求每个调用方都主动检查，否则极易触发运行时异常。尤其在链式调用或流式处理中（如 service.findItems().stream().map(...)），一旦 findItems() 返回 null，程序立刻崩溃。
更严重的是，null 本身不携带类型信息，无法直接调用 size()、isEmpty() 或遍历，迫使开发者额外封装或兜底，增加冗余代码。
用 Collections.emptyList() 的正确姿势
Collections.emptyList() 返回一个**不可变、泛型安全、线程安全**的空 List，且是单例对象（多次调用返回同一实例），内存开销极小。
- 声明时指定泛型，避免编译警告：
return Collections.<string>emptyList();</string>或使用静态导入后写return emptyList(); - 适用于所有需要返回空集合的场景：查询无结果、配置未启用、权限无匹配项等
- 不要用于需后续修改的集合——它不支持
add、remove等操作，会抛UnsupportedOperationException
与 Optional> 的取舍
有人倾向用 Optional<list>></list> 表达“可能无结果”，但需注意：
- 如果业务语义上“空集合”和“无结果”含义一致（例如分页查不到数据就返回空列表），直接返回
emptyList()更自然，调用方无需解包 - 若需区分“查不到”（null/empty）和“查到但结果为空集合”（逻辑上罕见），才考虑
Optional；多数场景属于过度设计 -
Optional主要用于**可能不存在的单个对象**（如findById），而非集合容器
统一团队规范的小建议
在项目中推动该习惯落地，可结合以下措施：
- 在公共工具类或基类中封装常用空集合：
Lists.empty()、Sets.empty()（基于Collections方法） - 静态代码检查（如 SonarQube）配置规则，扫描方法签名含
List/Set返回值却存在return null - Code Review 明确要求：所有集合返回值禁止为
null，优先用emptyXxx()，必要时用new ArrayList()（仅当需后续 add）
