Stream.filter通过多次调用实现多条件链式过滤，每次筛选保留满足当前条件的元素，最终得到同时满足所有条件的子集；条件顺序影响性能但不影响结果正确性。
Stream.filter 怎么实现多条件链式过滤
Java 8 的 Stream.filter 本身不支持“一次传入多个谓词”，但可以通过多次调用 filter 实现链式效果——每次只保留满足当前条件的元素，后续 filter 在前一次结果上继续筛选。
关键不是“合并条件”，而是“顺序裁剪”：每轮 filter 都生成新流，最终得到的是同时满足所有条件的子集。
- 写法直观：
list.stream().filter(p1).filter(p2).filter(p3)，逻辑清晰、可读性强 - 短路行为不受影响：只要某次
filter返回false，该元素直接被丢弃，不会进入下一轮 - 性能无额外开销：JVM 会将连续的
filter合并为单次遍历（在大多数常见场景下） - 调试友好：可单独注释某一层
filter快速验证逻辑
filter 链中条件顺序会影响性能吗
会影响，尤其当某些谓词计算成本高、或能快速排除大量元素时。把“快 + 高淘汰率”的条件放在前面，能显著减少后续谓词的执行次数。
例如过滤用户列表：filter(u -> u.isActive())（字段访问，毫秒级）应放在 filter(u -> userService.isPremium(u))（远程调用，百毫秒级）之前。
- 错误顺序：
stream.filter(expensiveCheck).filter(cheapCheck)→ 每个元素都先走慢逻辑 - 推荐顺序：
stream.filter(cheapCheck).filter(expensiveCheck)→ 大量元素在第一层就被筛掉 - 注意：顺序不影响最终结果正确性，只影响中间计算量
如何复用 filter 条件避免重复写 lambda
把常用谓词抽成静态方法或常量，既提升可读性，也方便单元测试和复用。
比如定义：
public static final Predicate<User> IS_ACTIVE = u -> u.getStatus() == Status.ACTIVE; public static final Predicate<User> HAS_EMAIL = u -> u.getEmail() != null && !u.getEmail().isBlank();
- 使用时：
users.stream().filter(IS_ACTIVE).filter(HAS_EMAIL) - 组合谓词可用
Predicate.and()或Predicate.or()，但要注意这会失去链式调试优势 - 避免在 lambda 内部捕获可变变量（如循环中的
int i），否则可能引发意外行为
filter 链里抛异常怎么办
filter 接受的 Predicate 不允许抛受检异常（Exception），如果内部逻辑可能抛出（比如调用含 IOException 的方法），必须包装或转换。
- 常见错误写法：
filter(u -> userRepo.findById(u.getId()).isPresent())→ 若findById抛SQLException，编译失败 - 正确做法：封装工具方法，把受检异常转为运行时异常，或提前处理好数据（如预加载 ID 集合）
- 更稳妥的方式是把 IO 操作移出 stream 流水线，在
filter前完成数据准备
链式 filter 看似简单，真正容易出问题的地方其实是条件之间的依赖关系、异常边界、以及对“流是否真的只遍历一次”的误判——别假设它会缓存中间结果，每次终端操作都会重新触发整个链。
