其实最安全的做法就是list != null && !list.isEmpty()这种短路表达式——将判空与后续操作捆绑在一起，当集合为null时后续逻辑根本不会执行。避免分开编写，也不要仅判空而不检查内容；更重要的是，如果方法返回集合，不要返回null，应使用空集合替代。至于入参，一进入方法就用Objects.requireNonNull()把校验提前完成。这套组合策略应用下来，空指针异常基本没有机会出现。
利用 && 将判空与后续操作写在同一个表达式里，就能在集合为 null 时自动跳过取值或遍历，从源头拦截空指针风险。这是最基础也最实用的防御手段。
判空与遍历务必写在同一个表达式中
短路保护只在单个布尔表达式内生效。只有把集合非空检查与它的使用绑定在一起，才能确保安全。来看两个对比：
- ✅ 安全：
if (list != null && !list.isEmpty()) { process(list.get(0)); }—— list 为 null 时，!list.isEmpty()不会执行，不会发生空指针。 - ❌ 危险：
if (list != null) { if (list.isEmpty()) { ... } }—— 虽然判了空，但后续单独写list.size()或list.forEach(...)时，如果未在该 if 块内执行，照样可能触发 NPE。很多隐患就是这样埋下的。
避免返回 null 集合，从根源上切断风险
方法返回集合时，不要返回 null，改用标准空集合。这是上游主动规避问题的最佳实践：
- 使用
Collections.emptyList()、Collections.emptySet()或Collections.emptyMap()替代return null; - 调用方拿到的是真实集合对象，可直接调用
.size()、.stream()、.forEach()，无需任何判空，代码更加简洁。 - 如果业务上需要区分“无数据”和“未初始化”，应通过状态字段或枚举来表达，而不是用
null作为语义载体——null能少用就少用。
入参校验放在方法最开头
对传入的集合参数，第一时间用 Objects.requireNonNull() 拦截。示例：
public void handleUsers(Listusers) { Objects.requireNonNull(users, "users must not be null"); ... } - 这样做既明确了契约，又让错误堆栈直接指向调用点，而不是深埋在某次
get(0)里，排查问题效率更高。 - 如果允许空集合但不允许
null，这一步就够了；如果空集合也非法，再加if (users.isEmpty()) throw ...
链式操作中逐级用 && 守住每一道关卡
访问嵌套集合结构（如 user.getOrders().get(0).getItems()）时，不能只判最外层。每一层都可能为 null，必须逐级防守：
- ✅ 正确：
if (user != null && user.getOrders() != null && !user.getOrders().isEmpty() && user.getOrders().get(0) != null && user.getOrders().get(0).getItems() != null) - 每一环都是前一环成立的前提，任一为 false，后面全部跳过。这样写虽然略显啰嗦，但能确保安全。
- 嵌套太深时建议改用 Optional 或工具类（如 Apache Commons 的
ObjectUtils.firstNonNull()），但短路逻辑仍然是底层基础——无论使用什么高级写法，最终执行的还是那套短路判空机制。
