优先使用 dynamic-datasource-spring-boot-starter（如3.6.1版）配置双Oracle数据源，它封装了ThreadLocal管理、@DS注解、事务兼容及连接池自动注册，避免手写AbstractRoutingDataSource在事务传播、AOP顺序、线程上下文清理等方面的高频坑。
spring boot 2.x 中配置 oracle 双数据源切换，核心不是“能不能配”，而是「路由逻辑是否隔离、事务是否可控、连接池是否独立」。直接用 abstractroutingdatasource 手写动态路由是可行的，但容易在事务传播、aop 顺序、线程上下文清理上出问题；更稳妥的做法是优先用 dynamic-datasource-spring-boot-starter，它把 threadlocal 管理、@ds 注解、事务兼容都封装好了。
为什么不用自己写 AbstractRoutingDataSource？
手写 AbstractRoutingDataSource 看似灵活，但实际踩坑密集：
-
determineCurrentLookupKey()返回 null 时会 fallback 到defaultTargetDataSource，但很多场景下你希望直接报错而不是静默降级 - 事务方法（
@Transactional）内切换数据源无效——Spring 事务绑定的是首次获取的 Connection，后续setDataSourceRouterKey()不会重连 - 异步线程（
@Async）、定时任务（@Scheduled）里 ThreadLocal 不继承，必须手动DynamicDataSourceContextHolder.set(...)+remove() - 没有内置健康检查或数据源热加载能力，新增第三个 Oracle 数据源要改代码、重启
用 dynamic-datasource-spring-boot-starter 配置双 Oracle 数据源
这是目前最省心、兼容 Spring Boot 2.1+ 的方案，支持注解级切换、默认主从标识、自动注册 Druid/Hikari 数据源。
步骤如下：
- 加依赖：
com.baomidou:dynamic-datasource-spring-boot-starter:3.6.1（注意：3.5.0+ 支持 Oracle 12c+ 的oracle.jdbc.driver.OracleDriver和oracle.jdbc.OracleDriver自动识别） - application.yml 中定义两个 Oracle 数据源，**key 名不能含点号（.）或下划线（_）开头**，例如用
ds1、ds2，别写成oracle.ds1—— 否则@DS("oracle.ds1")会解析失败 - 确保每个数据源的
driver-class-name显式指定为oracle.jdbc.OracleDriver（JDBC 4.2+ 推荐）或oracle.jdbc.driver.OracleDriver（旧版），避免 ClassNotFound - 不需写
DynamicDataSourceAspect切面类，starter 内置了；也不用手动调DBContext.changeDB()，直接注解即可
示例配置片段：
spring:
datasource:
dynamic:
primary: ds1
strict: false
datasource:
ds1:
driver-class-name: oracle.jdbc.OracleDriver
url: jdbc:oracle:thin:@192.168.1.100:1521:ORCL1
username: user1
password: pass1
ds2:
driver-class-name: oracle.jdbc.OracleDriver
url: jdbc:oracle:thin:@192.168.1.101:1521:ORCL2
username: user2
password: pass2@DS 注解在 Service 层失效？检查这三点
常见现象：加了 @DS("ds2") 但查的还是 ds1；或事务方法里切不动。本质是 AOP 生效时机和代理层级问题：
- 注解必须加在 **public 方法** 上，private / package-private 方法不被代理
- 不要在同一个类内部调用带
@DS的方法（比如 A.methodX() 调用本类的 B.methodY()），因为这是 this 调用，绕过代理 - 如果方法同时有
@Transactional和@DS，确保@DS切面@Order(-1)优先于事务切面（starter 默认已设好，但自定义切面可能覆盖）
Oracle CLOB 字段跨库查询失败？不是数据源问题，是驱动和 SQL 写法
双 Oracle 数据源本身不解决 CLOB 读写限制，但容易误判为切换失败。真实瓶颈在：
- Oracle JDBC 驱动对 CLOB 的流式读取要求 connection 必须保持 open，而某些连接池（如旧版 Druid）在 query 后自动 close stream，导致
getClob().getSubString()报SQLException: Closed Connection - MyBatis-Plus 默认不处理 CLOB 映射，需在
@SelectSQL 中显式用TO_CHAR(col)或配置typeHandlers - 跨库 JOIN 不被 Oracle 原生支持（DBLink 也不能查远程 CLOB），所以「双数据源切换」是唯一正解，但切换后仍要单独查、拼结果，不能写
SELECT * FROM ds1.table1 t1 JOIN ds2.table2 t2 ON ...
最后提醒一句：所有基于 ThreadLocal 的切换策略，在 WebFlux 或 Project Reactor 场景下天然失效——那是 Mono/Flux 的上下文，不是线程上下文。如果项目已上响应式栈，别碰 @DS，老实用两个独立 JdbcTemplate 实例手动控制。
