注解+反射驱动的轻量事务控制层比@transactional更可控、易测、适配分布式场景：通过自定义注解声明事务意图，反射动态调度try/confirm/cancel三阶段动作，支持补偿、幂等、重试，且不依赖spring aop代理链。
直接把长事务拆进注解+反射驱动的轻量控制层，比硬套@Transactional更可控、更易测、也更适配分布式场景。
核心思路：用自定义注解标记“事务边界”，用反射动态调度事务动作
不依赖Spring AOP代理链，也不把整个RPC调用链塞进一个@Transactional里。而是把事务逻辑显式切分为“准备→执行→确认/回滚”三阶段，由注解声明意图，反射在运行时按需组装和触发。
- 定义如
@DistributedTx(action = "orderPay", timeout = 30)这类语义化注解，标注在Service方法上 - 注解属性包含业务标识、超时时间、重试策略、补偿入口类等关键元数据
- 反射读取这些属性后，不直接执行业务逻辑，而是委托给统一的事务协调器（如TCC模式的Try-Confirm-Cancel调度器）
- 协调器通过反射调用对应Service的
tryXxx()、confirmXxx()、cancelXxx()方法，全程可记录、可拦截、可审计
反射如何安全支撑事务动作分发
避免手动写一堆if-else判断方法名，用反射+命名约定实现自动匹配：
- 假设注解中
action="inventoryDeduct"，协调器自动查找InventoryService.tryDeduct()、.confirmDeduct()等方法 - 使用
Class.getDeclaredMethod(name, paramTypes)获取方法，配合setAccessible(true)绕过private限制（仅限内部模块） - 参数通过反射从原始调用上下文提取并自动转换类型，例如把DTO字段映射为方法入参对象
- 异常统一捕获，触发回滚路径，并将失败原因、堆栈、事务ID写入本地日志+消息队列用于后续人工干预或自动补偿
注解属性驱动补偿与幂等控制
长事务最难的是失败后的一致性恢复。注解属性就是天然的补偿配置中心：
-
@DistributedTx(compensateBy = InventoryCompensator.class)：指定补偿执行器类，反射实例化并调用其rollback() -
idempotentKey = "userId:orderId"：生成唯一幂等键，事务协调器自动查Redis判断是否已执行，避免重复提交 -
retry = @Retry(maxAttempts = 3, backoff = 1000)：反射读取重试配置，封装成带退避的循环调用逻辑 - 所有关键动作（Try/Confirm/Cancel）执行前，先用反射获取当前方法上的注解值，动态构造事务上下文（含traceId、bizType、version等）
为什么比@Transactional + 远程调用更可靠
标准@Transactional在跨服务调用时会失效，且无法感知下游服务是否真正完成。而注解+反射方案把事务控制权收归本地：
- 每个远程步骤都包装成独立可重试、可补偿的原子动作，不受JVM线程生命周期影响
- 事务状态存在本地DB或Redis，不依赖数据库连接长期持有
- 反射调用过程可被AOP增强——加日志、埋点、熔断、降级，不影响业务代码干净度
- 测试时可Mock协调器，用反射替换真实Service实例，单元测试覆盖所有分支路径
