Predicate是Java 8引入的函数式接口，核心方法为test，用于对给定参数做布尔判断。真正让Predicate在条件筛选中大放异彩的是它的三个默认方法：and、or和negate。这三个方法允许把多个Predicate实例组合成一个新的Predicate，从而在不修改原有判断逻辑的前提下，灵活构建复杂的布尔表达式。与直接在业务代码里写多层if-else或者用&&、||拼接条件不同，Predicate组合方式把条件本身作为一等公民传递，可以赋值给变量、作为方法参数、存入集合，极大提高了规则的可维护性。
从接口定义来看，and方法接收另一个Predicate，返回一个新的Predicate，逻辑上等价于当前谓词与参数谓词的逻辑与。or方法同理实现逻辑或，negate则返回当前谓词逻辑非。它们内部实现利用了短路求值：and组合中当前置条件为false时不再计算后续条件，or组合中当前置条件为true时直接返回true。这避免了很多无谓的计算，也符合程序员的直觉预期。需要特别注意的是，链式调用中and的优先级并不天然高于or，Java语言中的&&优先级高于||，但Predicate接口的and和or属于方法调用，执行顺序取决于调用链的先后。如果希望实现类似&&优先的语义，必须在代码结构上通过分组调用明确表达。
Predicate的and与or基础用法
假设有一个商品实体，包含价格、库存、上架状态等属性。筛选逻辑要求“价格低于100元且库存大于0”。传统写法可能是在Stream的filter方法里放一个lambda表达式：product -> product.getPrice() < 100 && product.getStock() > 0。这种方式在条件简单时足够，一旦规则增加到五六个，lambda体会变得臃肿且难以测试。使用Predicate组合可以先把基础条件声明成独立变量。
Predicate<Product> priceBelow100 = p -> p.getPrice() < 100;
Predicate<Product> hasStock = p -> p.getStock() > 0;
Predicate<Product> affordableStock = priceBelow100.and(hasStock);
List<Product> result = products.stream()
.filter(affordableStock)
.collect(Collectors.toList());
这样每个基础谓词都可以单独进行单元测试，组合后的谓词也可以单独测试。当业务规则发生变化，比如价格上限调整为150，只需修改priceBelow100的lambda表达式，组合逻辑无需变动。and方法返回新实例，原priceBelow100和hasStock不受影响。这种不可变设计使得谓词可以安全地重复用于不同组合，不会产生副作用。
or方法适用于“满足任一条件即可”的场景。例如商品要么有折扣标记，要么库存大于10件才参与推荐。用or组合可以表示为：
Predicate<Product> isDiscounted = p -> p.isDiscounted(); Predicate<Product> stockMoreThan10 = p -> p.getStock() > 10; Predicate<Product> recommended = isDiscounted.or(stockMoreThan10);
实际使用中，and与or经常混合，形成类似构建判断树的链式调用。例如“价格低于100且（有折扣或库存大于10）”。由于方法调用从左到右执行，直接写priceBelow100.and(isDiscounted).or(stockMoreThan10)会变成(priceBelow100 && isDiscounted) || stockMoreThan10，丢失了预期分组。正确做法是先组合内部的or，再用and连接：priceBelow100.and(isDiscounted.or(stockMoreThan10))。通过显式分组，代码结构与逻辑树一一对应，减少了误读风险。
结合Stream API进行集合条件筛选
Stream的filter方法接受Predicate参数，因此组合后的Predicate可以直接传入。在处理复杂查询条件，尤其是前端传来的动态筛选参数时，Predicate组合的价值尤为突出。比如用户可能只填部分搜索条件，空条件不应参与过滤。此时可以构建一个基础谓词始终返回true，然后根据前端入参动态追加and条件。
Predicate<Employee> filter = e -> true;
if (StringUtils.isNotBlank(name)) {
filter = filter.and(e -> e.getName().contains(name));
}
if (minSalary != null) {
filter = filter.and(e -> e.getSalary() >= minSalary);
}
if (department != null) {
filter = filter.and(e -> e.getDepartment().equals(department));
}
return employees.stream().filter(filter).collect(Collectors.toList());
这种“动态累积条件”的模式可以消除大量重复的if判断和临时集合操作。每个新增条件都通过and方法组合进现有谓词，最终交给Stream执行一次遍历。相比多次filter或者先筛再筛的写法，性能上没有额外损耗，因为Predicate组合内部只是方法调用对象，真正遍历数据时执行的仍然是短路逻辑。另一个好处是筛选条件可以独立提取成私有方法，比如上面的部门等值判断可以封装成inDepartment方法返回Predicate，便于在多个查询接口中复用。
当条件之间存在大量或关系时，动态累积or就会遇到相反的问题：初始谓词必须返回false，然后逐个or连接。例如从多个状态中筛选符合任一状态的订单，可以构建base为e -> false，再对每个状态累加or。不过需要注意的是，or组合中的短路发生在第一个条件为true时，后续条件不再求值。如果某个条件包含耗时操作（如远程调用），放置在or链的前端可以提升整体筛选效率，但要注意条件顺序对结果没有影响，只对性能有影响。
复杂业务规则中的Predicate组合实践
规则引擎轻量化是Predicate组合的另一大应用方向。当业务规则数量达到数十条，且经常需要增删或调整时，把每条规则写成独立Predicate，再通过配置决定它们之间的and/or关系，可以构建出易于维护的规则树。比如电商优惠券的使用条件可以拆解为：用户等级大于等于3且订单金额超过200，或者用户是新注册且订单金额超过50。用Predicate表达：
Predicate<Order> userLevel = o -> o.getUserLevel() >= 3;
Predicate<Order> amountOver200 = o -> o.getAmount() > 200;
Predicate<Order> isNewUser = o -> o.isNewUser();
Predicate<Order> amountOver50 = o -> o.getAmount() > 50;
Predicate<Order> couponCondition = userLevel.and(amountOver200)
.or(isNewUser.and(amountOver50));
这样的规则树可以进一步抽象成JSON或数据库配置，通过反射或映射生成对应Predicate实例。与重量级规则引擎相比，Predicate方案零依赖、学习成本低，适合中小规模规则场景。一旦规则逻辑复杂到需要优先级、权重、推理链，才考虑引入Drools等专用引擎。即便引入专用引擎，Predicate也可以作为规则表达的一种轻量实现，在原型开发和单元测试阶段快速验证规则正确性。
在数据校验模块中，Predicate组合同样可以替代手写的校验链。例如对用户注册信息的校验：用户名长度6到20个字符、密码至少8位且包含数字、邮箱格式正确。把这些校验分别写成Predicate，再用and连接成总校验器。如果每个基础校验器还通过negate提供反向语义，可以轻松生成错误提示对应的“不满足条件”集合。配合Java的Optional或自定义校验结果对象，可以优雅地返回第一条失败原因，而不是简单的布尔值。
Predicate组合的常见陷阱与性能考量
第一个陷阱是空指针异常。由于Predicate的test方法接收一个对象，组合后的谓词在应用到null值时不会自动跳过。例如Predicate<String> notEmpty = s -> s != null && !s.isEmpty()，如果直接对null调用notEmpty.test(null)其实没问题，因为lambda内部先判断了不等于null。但很多开发者容易写成s -> !s.isEmpty()，这样当filter处理包含null元素的Stream时，就会抛出NullPointerException。因此编写基础谓词时必须明确处理null，或者在传入filter之前先把null过滤掉。
第二个陷阱是类型推断在链式调用中的表现。Predicate接口的and方法签名是default Predicate<T> and(Predicate<? super T> other)，这意味着参数可以使用更宽泛的类型。大部分情况下编译器能正常推断，但在使用方法引用时偶尔会产生歧义。例如filter(StringUtils::isNotBlank)中的方法引用返回Predicate<String& gt;，如果再调用and期望Predicate<Object>可能不兼容。解决方法是为lambda显式加上类型注解或拆分成多个变量。
第三个陷阱与negate的叠加相关。and和or是左结合的，negate只作用于调用它的那个Predicate。例如A.and(B).negate()返回的是对(A && B)取反，而不是A && (!B)。如果想要对B单独取反，需要写成A.and(B.negate())。很多人在阅读链式调用时会混淆取反范围，建议在复杂表达式中使用局部变量保存中间结果，增强可读性。同时，避免过深的链式嵌套，一般超过三层就应当提取命名变量，否则代码看起来像是符号拼图。
性能方面，Predicate组合本身几乎不产生运行时开销，主要成本仍然来自每个基础谓词的test方法调用。如果基础谓词内部包含数据库查询、网络请求等重操作，那么组合后每次调用test都会触发这些重操作。在这种情况下，应当考虑把重操作提前缓存结果，或者将Predicate组合用于内存数据筛选，而不是直接打入DAO层。对于海量数据，优先使用数据库的WHERE条件，Predicate组合更适合已经在内存中的数据过滤和二次组合。另外，and链中把最可能为false的条件放在前面，or链中把最可能为true的条件放在前面，可以利用短路减少后续判断次数。
最后要强调，Predicate的and与or不是语法层面的逻辑运算符，而是普通方法调用。这意味着它们不能在lambda表达式内部被随意嵌套成与&&、||等效的优先级形式。设计组合表达式时，先把业务逻辑转换成布尔表达式树，再映射到Java代码的分组调用，可以有效避免优先级错误。配合单元测试覆盖每种组合分支，Predicate能成为Java开发中优雅处理条件筛选的利器。