用 Predicate 做集合过滤，别直接 new 匿名类
Java 8+ 里 Predicate 最常见的用途就是配合 Collection.stream().filter() 做条件筛选。但很多人一上来就写 new Predicate<string>() { ... }</string>，这不仅啰嗦，还失去函数式接口的可组合性优势。
正确做法是用 lambda 或方法引用：
-
list.stream().filter(s -> s.length() > 5)—— 简单逻辑直接 lambda -
list.stream().filter(String::isEmpty)—— 已有静态/实例方法优先用方法引用 - 避免在 lambda 里写多行逻辑；超过 2 行建议抽成独立方法，再用方法引用传入
Predicate.and() / or() / negate() 组合时注意执行顺序和短路
多个条件拼接不是简单“加法”，and() 和 or() 返回的是新 Predicate 实例，且内部按调用顺序执行，支持短路（类似 && 和 ||）。
常见错误：以为 p1.and(p2).or(p3) 等价于 (p1 && p2) || p3，实际没错，但容易忽略 p2 根本不会执行——如果 p1 返回 false，and() 就直接返回 false，p2 根本不调用。
立即学习“Java免费学习笔记（深入）”；
- 调试组合逻辑时，可在每个
Predicate里加System.out.println()观察是否被调用 -
negate()是取反，不是“跳过”，它仍会触发原 predicate 的执行，只是结果翻转 - 不要链式调用太多层（比如
a.and(b).or(c).and(d).negate()），可读性差，也难单元测试
自定义 Predicate 复用时，别把状态塞进实现类里
有人会写一个带字段的类实现 Predicate，比如 class MinLengthPredicate implements Predicate<string> { private final int min; ... }</string>。这本身没问题，但容易踩两个坑：
- 误以为该实例是线程安全的——如果
min被外部修改（比如通过 setter），并发 filter 就可能行为不一致 - 过度设计：90% 场景下，用
static工厂方法更轻量，例如static Predicate<string> minLength(int n) { return s -> s != null && s.length() >= n; }</string> - 如果真需要状态（比如计数、缓存），明确用
ThreadLocal或不可变封装，别依赖实例字段隐式共享
和 Spring Data JPA 的 ExampleMatcher 或 MyBatis-Plus 的 QueryWrapper 混用要小心
有些框架（如 Spring Data JPA 的 QueryByExampleExecutor）也接受 Predicate，但它们的语义和 Stream.filter 不同：前者是生成 SQL 条件，后者是内存计算。不能把 stream 的 Predicate 直接塞给 JPA 当查询条件。
- Spring Data JPA 的
ExampleMatcher不接受Predicate，它用的是自己的匹配规则（如matchingAny()） - MyBatis-Plus 的
QueryWrapper有lambdaQuery()，但它内部是构建 SQL AST，不是执行 Java 函数 - 混淆两者最典型的错误：在 service 层对数据库结果用 stream.filter 写业务逻辑，却误以为能下推到数据库——查出来的数据量大会拖垮性能
真正难的不是写对一个 Predicate，而是分清它在哪一层生效：JVM 堆里还是数据库引擎里。漏掉这个边界，后面排查慢查询或 N+1 问题就绕不出去。
