多数据源切换失败时事务回滚无效，因事务绑定早于数据源切换；正确做法是避免同事务内混用多数据源，必要时用REQUIRES_NEW分段事务或分布式事务框架。
多数据源切换失败时事务回滚不是单纯“捕获异常再 rollback”就能解决的问题，核心在于：事务绑定发生在连接获取时，而数据源切换若晚于事务开启，就已失效。直接 catch SQLException 并调用 rollback() 往往起不到预期效果——因为此时操作可能根本没走目标库，甚至事务本身已绑定到错误的数据源上。
事务与数据源切换的执行顺序必须理清
Spring 的 @Transactional 在方法入口触发，会立即从当前 默认或已确定的数据源 获取 Connection 并绑定到线程（通过 TransactionSynchronizationManager）。此后所有 DAO 操作复用该 Connection。即使你在方法内用 @DS("slave") 标注某个 Mapper，只要事务已开启，@DS 不会重建连接，只是尝试切换上下文——但底层 Connection 仍是事务开启时拿的那个。
所以常见现象是：@DS + @Transactional 同用 → 切换无效 → 操作主库 → 回滚也只回主库，从库变更早已提交，无法撤回。
真正有效的回滚前提：确保操作在正确数据源上执行
要让回滚有意义，第一步是让数据库操作实际发生在你期望的数据源上。否则“回滚”只是对错误库做无用功。关键做法包括：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 避免在同一个 @Transactional 方法内混合操作多个数据源；如必须跨库，应拆分为独立事务
- 使用 @Transactional(propagation = Propagation.REQUIRES_NEW) 标注需切换数据源的子方法，强制新建事务、获取新连接
- 确保 @DS 注解作用在 非事务代理方法 上（例如 private 方法不生效），且被调用方未被同一事务包裹
- 检查 DataSourceTransactionManager 是否为每个数据源都正确定义，并在 @Transactional 中显式指定 transactionManager 属性
SQLException 捕获仅适用于手动事务场景
如果你绕过 Spring 声明式事务，用 JDBC 手动控制（比如在工具类中直接获取 Connection）：
- 务必先调用 connection.setAutoCommit(false)
- 所有 SQL 操作必须复用 同一个 connection 对象
- 在 catch(SQLException e) 中立即执行 connection.rollback()
- finally 中调用 connection.setAutoCommit(true) 并 close()
注意：这种写法无法解决多数据源切换问题，它只保证“当前 connection 上的操作可回滚”。若你本想操作从库却因切换失败连到了主库，rollback 的仍是主库——这不是异常处理的问题，而是数据源路由逻辑的问题。
推荐的健壮组合方案
生产环境建议采用分层策略：
- 读操作（查询）：用 @DS("slave") + 非事务方法，不加 @Transactional，切换自然生效
- 写操作（增删改）：只操作单一主库，用 @Transactional，默认走主数据源事务管理器
- 跨库写场景：放弃本地事务一致性，改用最终一致性方案（如发 MQ、记录对账表、定时补偿）；或引入 Seata/Atomikos 等分布式事务框架
- 确需局部跨库事务时：用 REQUIRES_NEW 分段隔离，各段独立回滚，不强求全局原子性
