Supplier与Optional结合不能彻底消除空指针异常，但能通过延迟求值和显式空语义显著降低其发生概率，关键在于主动重构空值敏感逻辑，而非接口组合本身。
Java中用Supplier配合Optional不能“彻底消除”空指针异常，但能显著降低其发生概率，并让空值处理更显式、更安全。关键不在于接口组合本身，而在于你是否主动用它重构空值敏感的逻辑。
Supplier + Optional 的真实作用：延迟求值 + 显式空语义
Supplier
常见误用是直接写 Optional.of(supplier.get()) —— 这毫无意义，supplier.get() 一旦抛NPE，Optional根本没机会介入。
正确姿势是：
立即学习“Java免费学习笔记（深入）”；
- 用 Optional.ofNullable(supplier.get()) 包裹可能为null的原始结果（注意：此时supplier.get()仍可能抛NPE，所以supplier内部必须保证不抛）
- 更推荐：用 Optional.ofNullable(null) 或 Optional.empty() 显式构造空，再用map/flatMap链式处理；Supplier只在真正需要时才被调用（例如作为默认值提供者）
典型安全模式：orElseGet 与 computeIfAbsent 的替代方案
当需要“获取值，若为空则计算默认值”时，orElseGet(Supplier) 是最常用且安全的组合：
- ✅ 安全：supplier只在Optional为空时才执行，避免了无谓计算，也规避了提前触发NPE的风险
- ❌ 避免 orElse(new ExpensiveObject())：构造函数或表达式会在任何情况下执行，浪费资源且可能抛异常
- 例子：configValue.map(Integer::parseInt).orElseGet(() -> getDefaultPort()) —— 只有配置为空或解析失败时，才调用getDefaultPort()
进阶用法：用Supplier封装可能失败的操作，再转为Optional
很多I/O、反射、解析操作天然可能返回null或抛异常。可封装为Supplier，再用工具方法转为Optional：
- 手动包装：Optional.ofNullable(() -> { try { return riskyParse(input); } catch (Exception e) { return null; } }).map(Supplier::get)（不推荐，冗长）
- 更清晰做法：写一个静态工具方法 safeGet(Supplier
) ，内部捕获NullPointerException和RuntimeException，返回Optional.empty()或Optional.of(result) - 实际效果：把“可能崩溃的调用”变成“确定返回Optional”，调用方只需处理Optional，无需层层try-catch
重要提醒：它们不解决根本问题
Supplier和Optional无法阻止以下情况：
- Supplier实现里自己写了 obj.toString() 而obj为null
- 从外部接收的参数未校验，直接传给Supplier使用
- Optional.get() 被滥用（应优先用map/flatMap/ifPresent）
- 数据库查询返回null，而你忘了用ofNullable包装
真正的防御靠三件事：参数校验（Objects.requireNonNull）、明确契约（文档或类型如Optional
