Optional不能彻底消除空指针，它仅封装判空逻辑且仅对Optional类型生效；误用of(null)会立即抛NPE，应优先使用ofNullable()并让方法签名主动返回Optional。
Optional 链式调用不能“彻底消除”空指针判空
直接说结论：Optional 本身不是空安全的银弹，链式调用（如 map、flatMap、orElse）只是把显式 if (x != null) 搬到了函数式表达里，底层仍依赖判空逻辑。它不消除判空，而是封装判空——且只对 Optional 类型生效，对原始引用（比如方法返回 null 而非 Optional）完全无效。
常见误用是：把一个可能为 null 的对象强行包装成 Optional.of(obj)，结果一运行就抛 NullPointerException ——因为 Optional.of 明确拒绝 null。
- 正确起点是：方法签名主动返回
Optional<T>，而非T - 错误起点是：外部把
null塞进Optional.of，或对未校验的字段直接调用get() -
Optional链式调用只有在整条链都基于Optional构建时才“看起来”无判空，一旦中间某步返回原始引用，链就断了
什么时候该用 Optional.empty() 而不是 Optional.ofNullable()
Optional.ofNullable() 是唯一安全接收 null 的工厂方法；Optional.of() 仅用于你 100% 确认非空的场景。但很多人混淆两者用途，导致 NPE 出现在构造阶段而非业务逻辑中。
典型反例：
Optional<User> userOpt = Optional.of(getUserFromDb(id)); // getUserFromDb 可能返回 null → NPE
应改为：
Optional<User> userOpt = Optional.ofNullable(getUserFromDb(id));
- 所有从外部系统、数据库、HTTP 响应等获取的值，一律用
ofNullable -
of只适合内部已做判空后的确定值，例如Optional.of(Objects.requireNonNull(user)) - 不要在流操作中对
Optional再套一层ofNullable：比如list.stream().map(Optional::ofNullable).map(Optional::get)——这等于绕了一圈又把null拿回来
flatMap 是 Optional 链式调用不崩的关键
当你需要从一个 Optional<A> 中提取另一个可能为空的值（比如 A.getName() 返回 String，而你想再取 name.length()），必须用 flatMap，而不是 map。否则会得到 Optional<Optional<Integer>>，后续调用 get() 或 orElse 就会出错。
示例：
Optional<User> userOpt = Optional.ofNullable(findUser(123)); // ❌ 错误：map 返回 Optional<Optional<String>> Optional<Optional<String>> nameOptOpt = userOpt.map(u -> Optional.ofNullable(u.getName())); // ✅ 正确：flatMap 展平一层 Optional<String> nameOpt = userOpt.flatMap(u -> Optional.ofNullable(u.getName()));
-
map适用于返回普通值（非Optional）的函数 -
flatMap适用于返回Optional的函数，它自动展平，维持单层结构 - 如果嵌套调用多层（比如
user.getAddress().getCity().getName()），每一步都要用flatMap+ofNullable，写起来啰嗦但安全
Optional 无法解决字段级空安全，Lombok @NonNull 和 IDE 检查更实际
Optional 是运行时机制，对字段是否可空没有约束力。你声明 private Optional<String> name;，依然可以赋值 null，JVM 不拦着。IDE 和编译器也默认不报错。
真正减少空指针的地方在定义侧：
- 用 Lombok
@NonNull标记构造参数或 setter 入参，生成非空校验代码 - 启用 IDE 的空值分析（如 IntelliJ 的 “Nullability annotations”），配合
@Nullable/@NotNull - Spring Boot 2.6+ 默认开启
spring.main.allow-bean-definition-overriding=false，间接减少因配置缺失导致的nullBean - 比起在业务逻辑里堆
Optional链，优先让 DAO 层返回Optional，服务层契约明确，避免下游反复包装
最常被忽略的一点：日志和监控里打印 Optional.toString() 得到的是 Optional[xxx] 或 Optional.empty，而不是值本身——调试时容易误判“有值”，其实只是 Optional 对象存在。
