应根据执行顺序需求选择：andThen先执行当前函数再执行参数函数，compose则相反；类型必须严格衔接，需主动处理null，避免混用Predicate/Consumer，性能敏感时宜内联而非过度组合。
Function.compose 和 Function.andThen 到底该用哪个
组合两个 Function 时，顺序决定执行流向：用 andThen 是先执行当前函数、再执行参数函数；compose 则相反——先执行参数函数，再执行当前函数。很多人写反了，结果输入输出类型对不上，编译直接报错 Cannot resolve method 'apply'。
- 想表达 “先转成字符串，再转成大写”，写成
toStringFn.andThen(toUpperFn) - 想表达 “先解析 JSON 字符串，再取 name 字段”，写成
jsonParseFn.compose(jsonString -> jsonString)更自然（但通常直接链式调用更清晰） - 注意：两个函数的输入/输出类型必须严格衔接，比如
Function<string integer></string>后接Function<integer boolean></integer>才能用andThen
避免 null 输入导致的 NullPointerException
Function 不处理 null 安全性，一旦上游传入 null，apply 方法里没判空就会炸。这不是接口设计缺陷，而是 Java 函数式 API 的默认契约：你得自己兜底。
- 别依赖
Optional.ofNullable(x).map(f).orElse(null)来“补救”——这属于在组合链外绕路，掩盖问题 - 更合理的做法是在具体实现里提前 guard：比如
s -> s == null ? "" : s.trim() - 如果多个环节都可能为 null，考虑用
Function<t optional>></t>替代原始类型，但要注意后续所有组合函数签名都要同步改
实际管道中混用 Predicate 和 Consumer 怎么办
Function 只能返回值，不能终止流程或做副作用。想在管道中间加日志、校验或短路逻辑，硬塞 Function 会别扭甚至出错。
- 校验场景：用
Predicate做守门员，配合Optional实现短路——input -> predicate.test(input) ? Optional.of(function.apply(input)) : Optional.empty() - 日志场景：别写
x -> { log.info(x); return x; }这种“假函数”，它破坏纯函数语义，且容易被 JIT 优化掉；改用peek（Stream）或单独抽离 side-effect 步骤 - 千万别把
Consumer强转成Function返回null，会导致下游NullPointerException难以定位
性能敏感场景下链式组合的真实开销
每次调用 andThen 或 compose 都会新建一个匿名 Function 实例，内部封装一层委托调用。对吞吐量高、单次处理极快的场景（比如每秒百万级字符串 trim + split），对象分配和虚方法调用会成为瓶颈。
立即学习“Java免费学习笔记（深入）”；
- 简单操作（如
String::trim、Integer::parseInt）建议直接手写内联逻辑，而不是层层组合 - 如果必须复用组合逻辑，考虑将常用链预构建为静态常量：
public static final Function<string integer> PARSE_TRIMMED = s -> Integer.parseInt(s.trim());</string> - 用 JMH 测过：10 层
andThen链比等效内联代码慢约 15%~25%，GC 压力也明显上升
函数组合看着优雅，但真正落地时，类型衔接、null 处理、副作用位置和对象生命周期这四点，最容易在上线后暴露出来。
