指针为空时创建新对象取字段是否合理？空安全最佳实践问询

首先明确结论：入参为null时直接创建空对象获取字段的做法绝大多数场景下都不合理，你给出的两种写法都有各自的缺陷，具体分析如下：

第一种写法（Optional兜底创建空User） #

UserInfo myMethod(User user) {
    user = Optional.ofNullable(user).orElse(new User());

    String name = user.getName();
    String type = user.getType();

    return new UserInfo(name, type);
}

这种写法的问题非常明显：

• 风险更隐蔽：你新创建的空User对象的name、type字段大概率也是null，相当于把入参的空指针风险转移给了UserInfo的调用方，而且调用方拿到的是不为null的UserInfo对象，很容易漏做字段判空，反而更容易触发隐藏的空指针问题
• 不必要的性能开销：虽然单次创建对象开销不大，但如果该方法属于高频调用场景，额外产生的空对象实例会带来无意义的GC压力
• 潜在副作用：如果User类的构造逻辑包含额外的初始化操作，凭空创建空对象还可能触发意料之外的业务逻辑错误

第二种写法（判空直接返回null） #

UserInfo myMethod(User user) {
    if(user == null) { return null; }
    
    String name = user.getName();
    String type = user.getType();

    return new UserInfo(name, type);
}

这种写法比第一种更直白，没有多余的对象创建开销，但同样有缺陷：返回null相当于把判空的责任完全甩给了方法调用方，一旦调用方漏做非空校验就会直接触发空指针异常，没有从根源上解决空安全问题。

更推荐的处理方案 #

根据不同的业务场景选择对应处理方式：

• 如果业务规则明确要求入参user不允许为null：采用fail fast原则，入口直接抛出明确的参数异常，避免空值往下传递：

  if (user == null) throw new IllegalArgumentException("入参User不能为空");
  

• 如果业务允许user为null，且存在明确的默认值：直接返回填充了默认字段的UserInfo，不要返回null或者半空的对象：

  if (user == null) return new UserInfo("默认用户名", "普通用户");
  

• 如果业务允许user为null且无默认值：返回Optional<UserInfo>而非null，强制调用方处理空场景，从语法层面降低漏判概率：

  return Optional.ofNullable(user).map(u -> new UserInfo(u.getName(), u.getType()));
  

• 方法尽量不要返回null，优先返回空集合、业务默认值或者Optional容器
• 入参非空校验优先采用fail fast原则，不要把空值传递到后续业务逻辑中
• 不要用无有效字段的空业务对象来规避空指针，这种做法只会隐藏问题，提升排查成本
• 业务模型设计时尽量将必填字段定义为非空类型，从类结构层面降低空指针出现的概率

内容的提问来源于stack exchange，提问作者Alexander.Iljushkin