filter本质是条件拦截而非空值过滤，仅对非空且满足断言的Optional保留原值，empty或断言失败均返回empty；误用易致NPE或空值穿透，需分层防御null与业务逻辑。
filter 方法的本质是条件拦截，不是空值过滤
filter() 不会处理 null，也不会跳过空的 Optional；它只对「有值且满足 predicate 条件」的 Optional 保留原值，其余一律转为 Optional.empty()。也就是说，如果上游已经是 Optional.empty()，filter() 直接透传空值，不执行断言逻辑——这点常被误认为“能过滤 null”，实际它连 null 都碰不到。
典型误用：Optional.ofNullable(user).filter(u -> u.getAge() > 18).map(User::getName)，当 user 为 null 时不会报错，但若 user 非空而 user.getAge() 返回 null，就会触发 NullPointerException（因为 filter 内部调用了 u.getAge() > 18）。
- 必须确保 predicate 中所有字段访问都已非空（比如先用
map提取再filter） - 想安全判断年龄，应写成：
.map(User::getAge).filter(age -> age != null && age > 18) -
filter()的返回类型仍是Optional<t></t>，不能直接解包，后续仍需orElse等收尾
和 map + isPresent 混用时容易漏掉空值穿透
有人试图组合使用：opt.filter(...).isPresent() ? opt.map(...).get() : "default"，这不仅破坏了链式表达的初衷，还让空值在 filter 后仍可能进入 map 阶段——因为 filter 返回空 Optional，map 会直接返回空，但 get() 调用会抛 NoSuchElementException。
正确姿势是把整个逻辑压进一条链：
String name = Optional.ofNullable(user)
.filter(u -> u.isActive())
.map(User::getProfile)
.filter(p -> p != null && p.isVerified())
.map(Profile::getNickname)
.orElse("访客");
- 每层
filter前，确保上一步输出的是非空对象（如map(User::getProfile)可能返回null，所以紧接着用filter(p -> p != null && ...)） - 不要在链中混用
isPresent()或get()，否则链式中断、空值隐患重现 - 如果业务条件本身依赖外部状态（如查数据库），
filter不适用——它只适合纯内存判断
filter 和 orElseGet 的配合决定默认值时机
filter() 之后接 orElse() 还是 orElseGet()，会影响性能和副作用。例如：
Optional.ofNullable(order)
.filter(o -> o.getStatus() == OrderStatus.PAID)
.map(Order::getAmount)
.orElseGet(() -> calculateDefaultAmount());
-
orElseGet()只在filter后为空时才执行函数，适合含 IO 或计算开销的默认逻辑 -
orElse(new BigDecimal("0.00"))是立即求值，不管是否用得上 - 注意：如果
filter前某步已为空（如order为null），orElseGet同样会触发——filter不改变空值传播行为，只增加一层条件拦截
真实业务中 filter 的典型陷阱
最常见的翻车点是把业务规则硬塞进 filter，却忽略了它无法处理异常或异步逻辑：
- ❌
.filter(u -> userService.isValid(u.getId()))——filter内部不能抛受检异常，也不能 await - ❌
.filter(u -> u.getEmail().contains("@"))—— 若getEmail()返回null，NPE 立刻发生 - ✅ 正确写法是先提取再判空：
.map(User::getEmail).filter(e -> e != null && e.contains("@")) - ✅ 复杂校验应提前封装为纯函数：
.filter(UserValidator::isEligible)，且该函数内部已处理所有null分支
真正难的从来不是写对一行 filter，而是厘清「哪一层该做空值防御」「哪一层该做业务拦截」——这两者在链式调用里必须严格分层，混在一起就等于把 null 问题从 if 块里搬进了 lambda 里。
