optional不能彻底消灭空指针校验，但能将分散的if判空转为清晰可组合的链式表达；仅应用于可能无结果的方法返回值，避免用于字段、参数或序列化场景。
用 Optional 并不能“彻底消灭”空指针校验，但它能帮你把空值处理从散落在各处的 if (obj != null) 转变为清晰、可组合、语义明确的链式表达——前提是用对地方、不滥用。
别把 Optional 当成 null 的“包装糖衣”
Optional 的设计初衷是作为方法返回值的契约声明：「这个方法可能不返回有效结果」。它不是为包装任意变量或字段而生的。
- ❌ 错误用法：给字段、参数、集合元素套
Optional（如private Optional<string> name;</string>），这增加内存开销、破坏序列化兼容性、让 API 更难用 - ✅ 正确场景：只用于返回值，尤其是那些天然可能“无结果”的操作，比如
Map.get()、查找方法、解析方法 - 例子：把
public User findUserById(Long id)改成public Optional<user> findUserById(Long id)</user>，调用方自然知道要处理“找不到”的情况
用 map/flatMap/filter 替代嵌套 if
当需要连续访问多层对象属性且每层都可能为空时，Optional 链式调用比层层判空干净得多。
- 传统写法：
if (user != null && user.getAddress() != null && user.getAddress().getCity() != null) { ... } - Optional 写法：
Optional.ofNullable(user)<br> .map(User::getAddress)<br> .map(Address::getCity)<br> .filter(city -> city.length() > 0)<br> .ifPresent(System.out::println);
- 关键点：每个
map在遇到空值时自动短路，无需手动检查；filter可做业务逻辑判断，也自动跳过
避免 isPresent() + get() 这种“换汤不换药”写法
这是最常见的退化用法——用 Optional 包了一圈，最后还是写 if (opt.isPresent()) { opt.get().doSomething(); }，和原始判空没本质区别。
- 优先用
ifPresent()、orElse()、orElseGet()、orElseThrow() - 需要转换结果？用
map()或flatMap()，而不是先get()再处理 - 需要 fallback 逻辑？用
orElseGet(() -> computeDefault())（延迟计算），而非orElse(computeDefault())（立即执行）
警惕 Optional 在流、集合、JSON 序列化中的陷阱
Optional 不是通用容器，它不实现 Collection，也不该出现在 DTO、数据库实体或 JSON 响应中。
- ❌ Spring MVC 返回
ResponseEntity<optional>></optional>→ JSON 会序列化成{"present":true,"value":{...}}，前端无法直接消费 - ✅ 正确做法：Controller 层解包，转为
ResponseEntity.ok(user)或ResponseEntity.notFound().build() - ❌ Stream 中用
map(x -> Optional.of(x))→ 得到Stream<optional>></optional>，徒增复杂度 - ✅ 真正需要过滤空值：直接
stream.filter(Objects::nonNull)或stream.flatMap(Optional::stream)（Java 9+）
Optional 是工具，不是银弹。真正消灭丑陋空校验的，是合理的领域建模（比如用值对象替代 null）、防御性编程习惯，以及团队对“什么该返回 Optional、什么该抛异常、什么该约定非空”的统一认知。用得克制，才显得高级。
