java stream的filter需遵循分层筛、快前慢后、谓词可测原则：先字段级快速过滤，再轻量校验，最后耗时操作；复用静态predicate；快条件前置；保障空安全与异常处理。
Java Stream 的 filter 不是简单写个布尔表达式就完事，它是一套讲顺序、重复用、防异常的实战逻辑。核心在于“分层筛、快前慢后、谓词可测”，而不是堆条件或硬编码。
分层过滤：先筛大面，再抠细节
面对海量数据（如十万级用户列表），把所有条件塞进一个 lambda 里，既难调试又拖性能。正确做法是按执行速度和排除率逐层过滤：
-
第一层用字段访问或基础比较：比如
filter(User::isActive)或filter(u -> u.getAge() >= 18)，毫秒级，能快速剔除 80% 以上无效数据 -
第二层做轻量校验：如邮箱非空且已验证
filter(User::hasValidEmail)，避免空指针，也不涉及 IO -
最后一层才调耗时操作：比如查白名单城市
filter(u -> CITY_WHITELIST.contains(u.getCity()))，此时数据量已大幅减少
谓词复用：静态常量比 lambda 更可靠
重复写 u -> u.getStatus() == Status.ACTIVE 容易出错、难维护。应提前定义为可复用、可测试的谓词：
- 声明为
public static final Predicate<user> IS_ACTIVE = u -> Status.ACTIVE.equals(u.getStatus());</user> - 使用时直接链式调用：
stream.filter(IS_ACTIVE).filter(HAS_VERIFIED_EMAIL) - 单元测试可单独验证谓词行为，无需构造完整 Stream 流程
顺序即性能：快条件必须前置
filter 链顺序不影响最终结果，但极大影响执行效率。原则很明确：越快、排除率越高的条件越靠前。
- ✅ 推荐：先
filter(u -> u.getScore() > 80)（字段读取），再filter(this::callRemoteAuthApi)（远程调用） - ❌ 避免：反过来写，会导致每个元素都触发一次耗时 300ms 的远程请求
- 典型快条件包括：
Objects::nonNull、Collection::contains（内存 Set）、简单正则匹配；慢条件包括 HTTP 请求、数据库查询、JSON 解析等
异常与空安全：别让 filter 崩在半路
filter 接收的 Predicate 不能抛受检异常，也不能容忍 null 元素引发 NPE：
-
空值守门：流中可能含 null？开头加
filter(Objects::nonNull)，再处理字段逻辑 -
受检异常包装：若内部需调用 throws IOException 的方法，用 try-catch 包装成 RuntimeException，例如：
s -> { try { return isValid(s); } catch (IOException e) { throw new RuntimeException(e); } } -
慎用 collect(toList())：若只需判断是否存在或取第一个，优先用
anyMatch()或findFirst()，避免无谓构建新集合
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
