spring默认事务管理器无法跨数据源，需为每个数据源配置独立datasourcetransactionmanager，并通过threadlocal+aop路由到对应管理器；强一致性场景应采用atomikos等jta方案实现两阶段提交。
在多数据源环境下，Spring 默认的 DataSourceTransactionManager 只能绑定一个数据源，无法直接跨多个数据源管理事务。要实现“动态切换底层事务管理器”，本质不是替换事务管理器本身，而是让事务上下文（TransactionSynchronizationManager）与当前线程所选的数据源保持一致——这依赖于动态代理 + 线程隔离 + 事务管理器路由的协同机制。
核心思路：事务管理器与数据源必须一一映射
每个数据源需对应一个独立的 DataSourceTransactionManager 实例。动态代理不直接“切换事务管理器”，而是确保 AOP 拦截到方法时：
- 先根据业务规则（如注解、参数、上下文）确定目标数据源标识；
- 将该标识存入
ThreadLocal； - 触发
AbstractRoutingDataSource路由到对应物理数据源； - 同时，事务拦截器（
TransactionInterceptor）通过PlatformTransactionManager获取事务，而这个管理器必须是预先为该数据源配置好的实例。
关键实现步骤
需要手动注册多个事务管理器，并让 @Transactional 注解能指向正确的那个：
-
声明多个
PlatformTransactionManagerBean：为每个数据源创建专属的DataSourceTransactionManager，Bean 名可按数据源命名（如primaryTransactionManager、secondaryTransactionManager）； -
自定义事务注解或扩展
@Transactional：标准注解不支持运行时指定管理器，因此常用做法是定义类似@DS("secondary")的注解，再配合 AOP 切面，在方法执行前把对应事务管理器设为当前线程的“默认事务管理器”； -
重写事务拦截逻辑：继承
TransactionAspectSupport或使用TransactionInterceptor的自定义变体，使其从 ThreadLocal 中读取当前应使用的事务管理器，而非固定使用容器中唯一的@Primary实例； -
避免事务传播冲突：跨数据源的操作不能放在同一个本地事务中（否则会报错或行为不可控），
REQUIRED传播下若方法调用链涉及多个数据源，需显式用REQUIRES_NEW隔离，或改用 JTA 分布式事务方案（如 Atomikos）。
为什么不能只靠 JDK/CGLIB 动态代理“换掉”事务管理器？
动态代理（JDK 或 CGLIB）负责的是方法调用的拦截和增强，它本身不持有事务管理逻辑。事务开启/提交/回滚动作由 TransactionInterceptor 触发，最终委托给 PlatformTransactionManager。代理层可以决定“调哪个管理器”，但必须提前准备好多个管理器实例，并在拦截时做路由选择——这不是代理技术的自动能力，而是开发者编排的控制流。
替代更稳妥的方案：用 JTA 管理跨数据源事务
如果业务真需原子性地操作多个数据源（例如主库写订单、从库写日志且要求一起成功/失败），本地事务管理器无法满足。此时应引入 JTA 实现，例如：
- 集成 Atomikos 或 Bitronix，配置
JtaTransactionManager； - 各数据源包装为
XADatasource，交由 JTA 事务协调器统一调度； - 仍用
@Transactional，但底层由 JTA 完成两阶段提交（2PC），不再依赖单个DataSourceTransactionManager。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
