函数式接口重载不能判定回滚边界，回滚由异常类型、事务配置和上下文策略决定；应按异常分类绑定策略、用函数式接口封装补偿动作、结合事务状态与上下文动态决策。

函数式接口的多载特性本身不提供回滚边界判定能力，它只是Java中支持Lambda表达式和方法引用的语法机制；真正决定“哪里该回滚、回滚到哪”的，是业务语义、异常类型、执行上下文和补偿策略——函数式接口仅用于封装这些逻辑，而非定义边界。

回滚边界由异常传播路径与处理契约决定，不是重载签名能推导的
Java中函数式接口（如Function<T,R>、Consumer<T>、Supplier<T>）允许你定义多个同名但参数不同的方法（即重载），但这只是编译期静态分发行为。JVM运行时不会根据参数类型自动选择“该不该回滚”：

• handleError(Exception e) 和 handleError(RuntimeException e) 是两个独立方法，调用哪个取决于传入实参的编译时类型，而非是否触发事务回滚
• 即使你为不同异常类型写了多个重载，若没有配合@Transactional(rollbackFor = ...)或显式TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，Spring根本不会回滚
• 重载无法感知调用栈深度、事务传播级别、远程服务响应状态等运行时关键信息

精准圈定回滚边界的三个实操落点
要让统一报错框架真正控制回滚动作，应聚焦以下可配置、可验证的设计点：

• 按异常分类绑定回滚策略
  在全局异常处理器（如@ControllerAdvice）中，对不同异常类型执行差异化动作：

  • BusinessException → 触发Saga补偿（调用Cancel接口）
  • TimeoutException → 主动发布“操作超时”事件，下游按幂等规则重置状态
  • DataAccessException → 直接触发本地数据库事务回滚（依赖@Transactional(rollbackFor = DataAccessException.class)）

• 用函数式接口封装补偿动作，而非判断边界
  把可逆操作建模为Supplier<Boolean>（执行补偿并返回是否成功），把不可逆操作建模为Runnable（只记录、不逆转）：

  // 补偿动作注册示例
  compensationRegistry.register("deduct-stock", () -> {
      stockService.restoreQuantity(orderId, quantity);
      return true;
  });

  边界定义在注册时（比如只给“扣库存”注册补偿，不给“发短信”注册），而不是靠重载函数签名推断。

• 结合事务传播与上下文标记动态决策
  在统一异常处理入口处检查当前事务状态和业务上下文：

  • 若TransactionSynchronizationManager.isActualTransactionActive()为false，说明不在事务内，跳过回滚，改走异步补偿
  • 若请求头含X-Compensate-Enabled: false，则禁用所有自动补偿，只记录告警
  • 若当前操作属于Saga链路第3步且前2步已提交，则只回滚第3步本地状态，不触发前序Cancel

把回滚边界寄托在函数重载上，就像靠菜单名字判断厨房有没有灭火器——名字再丰富，也不等于有安全机制。