if (null != obj) 是轻量、明确、零开销的运行时防护开关，适用于高频路径和入口校验；Optional 是对“值可能不存在”的语义建模，强调契约表达与链式安全处理，二者定位不同、不可互替。

直接说结论：if (null != obj) 是轻量、明确、零开销的防御手段；Optional 是语义清晰、可组合、面向值存在性建模的抽象工具——它不“替代”判空，而是重构判空的意图。二者适用场景不同，混用或强推某一种都容易出问题。

if (null != obj) 的真实定位

这是最底层、最直接的防御动作，本质是运行时防护开关：

• 无对象创建开销，无函数调用栈膨胀，适合高频路径（如循环内、IO回调、RPC入参校验）
• 逻辑直白，调试时变量状态一目了然，IDE 和 debugger 可直接观测 null 状态
• 适合做“守门员”：方法入口参数校验、外部数据落库前兜底、配置项强制非空断言
• 不解决嵌套判空的可读性问题，但配合三元运算符（obj != null ? obj.getFoo() : null）已足够简洁

Optional 的核心价值不在“防NPE”，而在“表达意图”

Optional 不是 null 的包装器，而是对“值可能不存在”这一语义的显式建模。它的优势体现在设计契约层面：

• 方法返回 Optional<T> 时，调用方必须主动处理“无值”分支（编译期提醒），无法假装看不见
• map/filter/flatMap 链天然抑制空传播，避免手写多层 if 嵌套，尤其适合处理 user.getAddress().getCity().getName()
• orElse/orElseGet/orElseThrow 强制你声明“当值缺失时怎么办”，而不是让 null 悄悄流到下游引发更隐蔽的 NPE
• 它本身绝不能为 null——这消除了 Optional 层级的二次空指针风险

关键误区与踩坑点

很多人用 Optional 反而引入新风险，原因在于误用：

• 把 Optional 当作通用 null 替代品：在字段、参数、集合元素中存 Optional，导致三层嵌套 Optional<Optional<String>>，得不偿失
• 滥用 isPresent() + get()：写成 if (opt.isPresent()) return opt.get(); 完全违背 Optional 初衷，比 if (obj != null) 更啰嗦且易出错
• 忽略性能敏感场景：高吞吐网关、实时计算引擎中，每毫秒创建数百个 Optional 实例会增加 GC 压力
• 返回 Optional 却不处理空分支：比如只写 opt.map(...).get()，等于把 NPE 从原处挪到了 get() 这一行

怎么选？看三个信号

不用纠结“哪个更好”，按上下文信号决策：

• 这是 API 的返回契约吗？→ 用 Optional（例如 Repository.findById(id) 应返回 Optional<User>）
• 这是内部临时变量或入参校验吗？→ 用 if (obj == null) 或 Objects.requireNonNull
• 要链式取深层属性且层级 ≥ 3？→ 优先用 Optional.ofNullable(obj).map(...).map(...).orElse(...)，比嵌套三元更安全可读