核心问题是事务未绑定正确数据源，需从代理是否生效、事务管理器是否匹配、数据源切换时机是否早于事务开启三方面排查。
多数据源环境下事务失效，核心问题不是“事务没加”，而是“事务没绑对库”。排查要从代理是否生效、事务管理器是否匹配、数据源切换时机是否早于事务开启这三点切入。下面分几个关键方向讲清楚怎么查、怎么看、怎么改。
看代理有没有真正介入
这是所有事务问题的第一道门槛。Spring事务靠AOP代理实现，如果调用没经过代理，@Transactional就形同虚设。
- 检查方法是不是在同一个类里被this.xxx()调用的——这种自调用绕过代理，事务必然不生效
- 确认该Service类上有@Service或@Component，且是通过@Autowired注入使用的；手动new的对象不会被Spring代理
- 查看启动日志里有没有类似"Creating shared instance of singleton bean 'xxxService'"，再搜"TransactionInterceptor"是否被注册——没注册说明@EnableTransactionManagement缺失或配置未生效
查事务管理器和数据源是否对得上
多个数据源必须配多个事务管理器，且@Transactional必须明确指定用哪一个，否则默认只认@Primary的那个。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 检查每个@Bean定义的DataSourceTransactionManager是否都加了@Qualifier，命名是否清晰（如primaryTransactionManager、slaveTransactionManager）
- 对应的方法上必须写成@Transactional("slaveTransactionManager")，不能只写@Transactional
- 验证方式：在方法入口打个断点，进到TransactionInterceptor.invoke()里，看transactionManager字段实际引用的是哪个实例，再顺藤摸瓜看它绑定的是哪个DataSource
盯紧数据源切换和事务开启的先后顺序
动态切换数据源（比如用@DS或ThreadLocal）如果发生在事务开启之后，那事务早就绑定了旧连接，切换无效。
- 确保数据源切换逻辑（如DataSourceContextHolder.set("slave")）在事务切面执行前完成——通常要放在Controller层或自定义AOP切面里，且@Order(Ordered.HIGHEST_PRECEDENCE)
- 避免在@Transactional方法内部手动调用setDataSource()，尤其不能在事务已开启后切换
- 用dynamic-datasource-spring-boot-starter这类成熟组件时，确认它内置的切面@Order值比TransactionAspectSupport更小（即优先级更高）
验事务是否真跨库生效
一个事务里操作多个数据源，本身就是反模式——JDBC事务天然只支持单连接。强行这么做，只会部分回滚。
- 如果业务确实需要跨库一致性，不要依赖Spring单事务，改用Seata、XA协议或最终一致性方案（如发MQ+本地事务表）
- 若只是读写分离，@DS("slave")应只用于查询方法，且这些方法不该加@Transactional；写操作统一走主库+事务管理器
- 日志里重点搜"Acquired Connection"和"Borrowed connection"，对比不同操作拿到的Connection对象hashCode是否一致——不一致就说明根本没在同一个事务里
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
