函数式接口不直接实现声明式事务拦截，而是增强事务逻辑表达力与可组合性，用于封装业务动作、动态决策事务属性及作为自定义拦截器的策略载体，但必须依托Spring事务上下文或代理机制生效。
函数式接口本身不直接实现声明式事务拦截，它不替代 @Transactional 注解，也不参与 Spring AOP 的代理织入过程。它的作用是增强事务逻辑的表达力、封装能力与可组合性——尤其在自定义事务拦截器（如 TransactionInterceptor）或构建轻量级事务模板时，提供简洁的行为抽象。
函数式接口用于封装事务行为逻辑
你可以用 Supplier、Consumer 或 Function 封装“需要在事务中执行的业务动作”，避免重复 try-catch 和手动控制 transactionManager：
- 定义事务执行模板：接收一个无参 Supplier
，在事务上下文中执行并返回结果 - 内部由 PlatformTransactionManager 管理 begin/commit/rollback，业务方只关注 lambda 里的核心逻辑
- 示例：transactionTemplate.execute(() -> userDao.update(user)) 中的 execute 方法参数就是函数式接口类型
配合 @Transactional 实现语义增强
@Transactional 是声明式入口，但某些场景需动态控制事务属性（如只读、超时、隔离级别）。此时可结合函数式接口做运行时决策：
- 用 Predicate
判断方法名是否走只读事务（如以 “get” “query” 开头） - 用 Function
动态生成事务定义，替代硬编码的 @Transactional(readOnly = true) - 这种组合常见于统一事务切面中，而非直接标注在业务方法上
在自定义事务拦截器中作为策略载体
当绕过 @Transactional、改用 TransactionInterceptor + Pointcut 手动装配时，函数式接口可用于组织拦截逻辑：
立即学习“Java免费学习笔记（深入）”；
- 定义 TransactionPolicy 函数式接口：boolean shouldApply(Method method)
- 多个 Policy 实例（如 ReadOnlyPolicy、RetryOnConflictPolicy）可组合成复合判断
- 拦截器根据 Policy 返回值决定是否开启事务、是否设置只读、是否重试等
- 比 XML 配置或硬编码 if-else 更易测试和替换
注意边界：不替代 AOP 机制
函数式接口不能让普通方法自动获得事务能力。它必须被显式调用，或嵌入到 Spring 已识别的拦截流程中：
- 直接 new Thread(() -> service.doInTx()).start() —— 不会触发事务
- 未被 Spring 代理的方法调用（this.method()）—— 即使有 @Transactional 也无效
- 函数式封装的动作，仍需运行在 Spring 管理的事务上下文内（如通过 TransactionTemplate 或 AOP 代理后的对象调用）
