该用 Predicate 而不是 Function：Predicate 专用于返回 boolean 的判断逻辑（如 filter），Function 专用于返回任意类型的转换逻辑（如 map）；混淆会导致编译错误、语义混乱及集成崩溃。
什么时候该用 Predicate 而不是 Function
Predicate 专用于“判断”，返回 boolean；Function 专用于“转换”，返回任意类型（包括 void 的变体是 Consumer）。选错接口会导致编译失败或语义混乱。
- 要过滤集合（如
Stream.filter()）→ 必须用Predicate<t></t>，例如Predicate<string> isEmpty = s -> s == null || s.trim().isEmpty();</string> - 要把
String转成Integer→ 必须用Function<string integer></string>，例如Function<string integer> parseInt = Integer::parseInt;</string> - 误把
Function<user boolean></user>传给filter()会报错：方法签名不匹配，因为filter()明确要求Predicate
Predicate 的链式组合为什么不能直接用 and/or 拼多个条件
Predicate.and() 和 or() 是二元操作，每次调用只合并两个谓词。连续链式调用看似简洁，但底层会嵌套多层匿名对象，影响可读性和调试——尤其当某个条件抛出异常时，堆栈里全是 Predicate$$Lambda。
- 推荐写法：先定义清晰变量，再组合
Predicate<Order> isPaid = o -> o.getStatus() == OrderStatus.PAID;<br>Predicate<Order> isShipped = o -> o.getShipmentDate() != null;<br>Predicate<Order> isEligibleForReview = isPaid.and(isShipped);
- 避免写法：
isPaid.and(o -> o.getAmount() > 100).or(o -> o.isVip())—— 条件逻辑混在一起，难以单元测试 -
negate()等价于!test()，但注意：它不会改变原始谓词行为，只是包装一层，不解决空指针问题
Function 的 andThen 和 compose 容易搞反执行顺序
f.andThen(g) 表示“先 f，再 g”；f.compose(g) 表示“先 g，再 f”。名字反直觉，且 IDE 很少提示参数类型流，容易在嵌套转换时出错。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 示例：把用户 ID 字符串转为大写再取前 5 位
Function<String, String> toUpper = String::toUpperCase;<br>Function<String, String> takeFirst5 = s -> s.substring(0, Math.min(5, s.length()));<br>Function<String, String> idProcessor = toUpper.andThen(takeFirst5); // 正确：先转大写，再截取
- 如果误用
compose：toUpper.compose(takeFirst5)，会先截取再转大写——但截取发生在转大写之前，输入可能是未处理的原始字符串，逻辑错位 - 涉及可能为
null的输入时，Function不自动判空；需手动加Objects.requireNonNull或用Optional包裹
实际项目中 Predicate 和 Function 混用的典型陷阱
常见于 DTO 转 Entity 或权限校验场景：有人试图用 Function 做判断（比如返回 Boolean），或用 Predicate 做转换（比如返回新对象），表面能编译，但破坏函数式接口契约，后续集成 Stream / Optional / 第三方库时会突然崩溃。
立即学习“Java免费学习笔记（深入）”；
- 错误示范：
Function<user boolean> isAdmin = u -> u.getRole().equals("ADMIN");</user>→ 传给filter()看似能用，但类型语义错误，团队协作时别人无法一眼识别这是个判断逻辑 - 正确做法：统一用
Predicate<user> isAdmin = u -> u.getRole().equals("ADMIN");</user>，哪怕只是临时变量 - 更隐蔽的问题：在 Spring Data JPA 的
@Query或 Criteria API 中，误把Function当作查询条件构造器，结果生成的 SQL 完全不符合预期——因为 JPA 不解析 Java 函数体，只认Predicate对应的CritieriaBuilder调用链
Predicate 就是问“是不是”，Function 就是做“变成什么”。混淆这两者，后面所有流式操作、测试桩、Mock 都会悄悄偏航。 
