Optional.filter用于对单个Optional值做条件判断，不适用于集合过滤；它接收Predicate作用于封装的值（若存在），常用于链式调用中提前终止，如findUserById(id).filter(User::isActive).map(User::getName)。
Optional.filter 的作用不是过滤集合，而是对单个 Optional 值做条件判断
很多人一看到 filter 就联想到 Stream.filter 或集合操作，但 Optional.filter 只接收一个 Predicate，作用对象是它自己封装的那个值（如果存在），不适用于“容器中多个对象”的筛选场景。
如果你手头是一个 List<user></user> 或其他集合，想按业务规则筛掉不符合条件的元素，直接用 Optional.filter 是无效的——它根本不会遍历、也不会返回新集合。
-
Optional.filter的典型用途是：链式调用中提前终止，比如findUserById(id).filter(User::isActive).map(User::getName) - 它返回的仍是
Optional，且最多只处理一个值 - 拿它处理
List会编译失败：list.filter(...)根本不存在
想筛集合？该用 Stream.filter 或传统循环
真正要实现“根据业务规则过滤掉容器中不符合条件的对象”，核心工具是 Stream.filter（Java 8+）或显式迭代。业务规则写成 Predicate 即可复用。
例如，筛选出状态为 ACTIVE 且积分大于 100 的用户：
List<User> validUsers = users.stream()
.filter(user -> user.getStatus() == Status.ACTIVE)
.filter(user -> user.getPoints() > 100)
.collect(Collectors.toList());
- 多个
filter可连写，语义清晰；也可合并成一个表达式提升可读性 - 注意：
Stream.filter不修改原集合，返回新List；若需就地过滤，用Collection.removeIf - 性能上，
Stream有轻微开销，但对千级以内数据几乎无感；超大集合且敏感时，传统for+Iterator.remove更可控
Optional.filter 和业务规则结合的真实用法
它真正起作用的地方，是在“可能为空的单个结果”上叠加业务校验。比如从缓存查用户、调第三方接口返回单个 Optional，再加一层规则拦截。
示例：查到用户后，只允许处理 VIP 用户的订单请求：
Optional<User> user = userRepository.findById(userId);
Optional<Order> order = user
.filter(u -> u.getLevel() == UserLevel.VIP) // ← 这里是 Optional.filter
.map(u -> orderService.createOrder(u));
- 如果
user为空，或非 VIP，整个链式调用直接短路，order为Optional.empty() - 业务规则（如
u.getLevel() == UserLevel.VIP）必须是纯函数、无副作用，否则难以测试和复用 - 别在
filter里写远程调用或数据库查询——这违背了Optional的设计初衷，也破坏了短路逻辑的确定性
容易误用的几个坑
最常见的混淆点，是把 Optional 当成轻量集合类型来用。它不是 List，也不是 Stream，只是一个“值存在性”的容器。
- 写
optionalList.filter(...)—— 编译报错，List没这个方法 - 写
optional.get().stream().filter(...)—— 先get()再流式处理，一旦optional为空就抛NoSuchElementException - 在
filter中抛异常或改状态 ——Predicate应该是无状态、无副作用的，否则后续 map/flatMap 行为不可预测 - 嵌套多层
Optional.filter处理集合元素 —— 逻辑绕、难调试，不如先 flatMap 出流再 filter
复杂业务规则本身不难写，难的是选对承载它的结构：集合用 Stream，单值用 Optional，混着用只会让代码既不安全也不清晰。
