可在不破坏闭包语义前提下用函数式接口封装异常处理，须保持签名不变、不泄露实现、不改变成功路径预期；包裹器应继承原接口异常能力、避免new/this引用、通过组合式链式调用组装纯函数handler、显式隔离副作用、谨慎翻译异常、禁用阻塞操作，并与default方法协同分层扩展。
可以在不破坏闭包语义的前提下，用函数式接口封装异常处理逻辑，核心是保持输入输出契约不变、不泄露实现细节、不改变调用方对“成功路径”的预期。
保持函数签名纯净
闭包的本质是捕获环境并延迟执行，其对外表现应与原始函数一致。因此，异常包裹器不能修改接口的参数类型、返回类型或是否抛出检查异常——否则就不再是“同一函数”，而是新契约。
- 若原始接口是
Function<String, Integer>，包裹后仍必须是该类型，不可变为Function<String, Result<Integer>>（除非所有调用方都适配） - 对
CheckedFunction<T,R>这类自定义函数式接口，包裹器应继承其异常能力，而非压制或转换为运行时异常，否则会丢失业务意图 - 避免在 wrapper 中引入 new 或 this 引用，防止闭包意外持有外部对象生命周期
用组合代替侵入
异常包裹器应作为独立工具链存在，通过方法链式调用组装行为，而不是侵入原始函数体或要求实现类继承特定基类。
- 像
FunctionChainWrapper那样，用onException()、logException()、fallback()等方法追加策略，build 后才生成最终函数实例 - 每个 handler 是纯函数：接收
Throwable，返回R，不修改状态、不依赖外部变量 - fallback 值应在 build 前确定，避免运行时动态计算导致闭包捕获不稳定变量
隔离副作用，明确错误边界
闭包强调无副作用和可预测性。异常处理中的日志、告警、重试等操作必须显式声明、可控开关，不能隐式触发。
- 默认
exceptionLogger是空 Consumer，启用前需显式调用logException(...) - 翻译异常（
translateException）应只做类型转换，不嵌套新异常链；如需保留原始栈，用RuntimeException(e)而非new RuntimeException("wrap", e) - 不支持在 handler 中发起远程调用或阻塞 I/O——这会打破函数式接口“轻量可组合”的前提
与 default 方法协同演进
当接口后续需扩展错误处理能力（如统一前置校验、后置审计），可用 default 方法提供可选钩子，与包裹器形成分层协作。
- 例如在函数式接口中声明
default boolean shouldRetry(Throwable e) { return false; }，包裹器内部可安全调用，不强求实现类覆盖 - default 方法不访问私有字段，也不修改状态，仅提供策略判断入口，符合闭包“只读环境”的原则
- 若某实现类需定制重试逻辑，只需覆写该 default 方法；其他类继续使用默认 false，零侵入升级
