Java多数据源切换失败不会自动回滚到默认源，需通过配置兜底（如dynamic-datasource的strict: false）、编程防御（try-catch+显式降级）和事务隔离（REQUIRES_NEW）来确保操作落在预期数据源且不破坏一致性。
多数据源切换失败时，Java 并不会自动“回滚到默认数据源”——这不是事务回滚，而是数据源路由异常后的兜底行为。真正的安全做法是：**提前预防切换失败 + 显式兜底 + 避免事务污染**。关键不在“回滚数据源”，而在“不让错误数据源参与事务”。
明确切换失败的典型场景
常见原因包括：
- ThreadLocal 中未设置或已清除数据源标识（如忘记调用
DynamicDataSourceContextHolder.setDataSourceType(DataSourceType.SLAVE)） - @DS 注解被事务代理拦截器忽略（如加在 private 方法或内部调用上）
- 事务已开启，AbstractRoutingDataSource 的
determineCurrentLookupKey()被跳过，沿用旧连接 - 配置中未定义对应 key 的数据源（例如代码传了 "backup"，但 yml 里只配了 master/slave）
配置层面强制兜底：dynamic-datasource 的 strict 模式
使用 dynamic-datasource-spring-boot-starter（推荐）时，在 application.yml 中启用严格模式并指定 fallback：
spring:
datasource:
dynamic:
primary: master
strict: false # 关键：设为 false，找不到时自动走 primary
datasource:
master:
...
slave:
...
当 @DS("slave") 失效或 key 不存在时，自动回落到 master，避免 NoSuchBeanException 或空指针。
立即学习“Java免费学习笔记（深入）”；
编程层面主动防御：try-catch + 显式重置
对关键读操作（如从库查询），不依赖注解自动切换，改用代码控制，并捕获路由异常：
- 手动设置上下文，执行后立即清理
- 捕获
IllegalStateException或DataSourceNotFoundException等路由异常 - 降级逻辑中显式切回主库，而非依赖默认 fallback
示例：
public List<User> queryFromSlave() {
try {
DynamicDataSourceContextHolder.setDataSourceType(DataSourceType.SLAVE);
return userMapper.selectAll();
} catch (Exception e) {
log.warn("从库查询失败，降级为主库", e);
DynamicDataSourceContextHolder.setDataSourceType(DataSourceType.MASTER);
return userMapper.selectAll();
} finally {
DynamicDataSourceContextHolder.clear(); // 必须清理，防止线程复用污染
}
}
事务方法中禁止跨源混用，用传播机制隔离
如果一个 @Transactional 方法内需操作多个数据源，直接切换会失败（事务绑定连接不可变）。正确做法是：
- 主事务只操作一个数据源（如写主库）
- 跨源读取或写入，拆到独立方法，并标注
@Transactional(propagation = Propagation.REQUIRES_NEW) - 该独立方法内再做数据源切换，确保它拥有自己的连接和事务上下文
这样即使从库操作失败，也不会影响主库事务；主库事务成功与否，也由自身决定，不耦合。
本质不是让系统“回滚数据源”，而是通过配置兜底、代码防御和事务隔离，确保每次数据库操作都落在预期的数据源上，出错时有明确路径可退，且不破坏一致性边界。
