AbstractRoutingDataSource 不能直接 new 使用，因其是抽象类，需继承并重写 determineCurrentLookupKey()，配置 targetDataSources 和 defaultTargetDataSource，并调用 afterPropertiesSet()，否则启动报错或运行时 NPE。
为什么 AbstractRoutingDataSource 不能直接 new 出来用
因为 AbstractRoutingDataSource 是个抽象类，核心逻辑在 determineCurrentLookupKey()，它不负责持有哪些数据源，只管“此刻该找谁”。你得继承它、重写这个方法，并把真实的数据源（比如 HikariDataSource）提前注册进 setTargetDataSources()。漏掉 afterPropertiesSet() 调用或没设 defaultTargetDataSource，启动时会报 IllegalStateException: DataSource router not initialized。
常见错误现象：NullPointerException 在执行 SQL 时抛出，实际是路由 key 返回了 null，而 defaultTargetDataSource 又没配。
- 必须重写
determineCurrentLookupKey()，返回值类型是Object，但要和targetDataSources的 key 类型一致（通常用String） -
targetDataSources是Map<object datasource></object>，key 必须和路由方法返回值完全匹配（注意大小写和空格） -
defaultTargetDataSource不是可选项——哪怕只用多数据源，也得设一个兜底，否则首次调用就崩
ThreadLocal + AOP 切面里怎么安全存取数据源标识
AOP 动态切换本质是：在方法执行前把 key 写进 ThreadLocal，路由类读取它；方法结束再清理，避免线程复用导致脏数据。但 Spring 的事务代理、异步线程（@Async）、定时任务（@Scheduled）都会脱离原始线程上下文，这时候 ThreadLocal 就失效了。
使用场景：Service 方法上加自定义注解 @DS("slave1")，AOP 拦截并设置 key；但若该方法内又调用了 @Async 方法，子线程拿不到父线程的 ThreadLocal 值。
- 别用静态
ThreadLocal字段裸奔，封装成工具类，提供set()、get()、clear()三件套 - AOP 的切点要用
@Around，且finally块里必须调clear()，否则 Tomcat 线程池复用时会串库 - 遇到
@Async或CompletableFuture，得手动传递 key，比如用TaskDecorator包装线程池，或在提交任务前把当前 key 存入CompletableFuture.supplyAsync(() -> ..., executor)的闭包里
多个 @Transactional 方法嵌套调用时，数据源切换为啥失效
根本原因是 Spring 事务代理默认只对**外部调用**生效。如果 A 方法加了 @Transactional 和 @DS("master")，内部直接调用同个类里的 B 方法（也标了 @DS("slave")），B 的 AOP 根本不会触发——因为没走代理对象，而是 this.B() 直接调用。
错误现象：明明 B 方法上了 @DS("slave") 注解，SQL 却还是打到 master 库，日志里也看不到 AOP 的切入痕迹。
- 解决办法只有两个：要么把 B 拆到另一个 Service 类里（确保走代理）；要么通过
ApplicationContext.getBean(XxxService.class)拿代理对象再调，但破坏了代码结构 - 更隐蔽的坑：事务传播行为是
REQUIRES_NEW时，新事务会开启新线程上下文，但你的ThreadLocal不会自动继承，得在事务模板里手动透传 key - 别依赖“先切数据源再开事务”的顺序——Spring 事务拦截器比数据源路由更早触发，所以 key 必须在事务开始前就写好
Druid 连接池 + 多数据源时，监控页面只显示一个数据源
Druid 的 DruidStatManager 默认只注册第一个 DruidDataSource Bean，其余会被忽略。这不是 bug，是设计如此：每个 Druid 数据源需要独立配置自己的监控路径（如 /druid/master、/druid/slave），否则所有指标都堆在默认路径下，看着像“只有一个”。
性能影响：如果不分路径，所有数据源的 SQL 统计混在一起，慢 SQL 定位、连接数水位判断全失真。
- 每个
DruidDataSourceBean 必须显式调setStatViewServletConfig()，指定不同url-pattern - 在
application.yml里配spring.datasource.druid.stat-view-servlet.url-pattern是无效的——它只作用于自动装配的单数据源场景 - 记得给每个 Druid 实例设唯一
name（setName("ds-master")），否则 JMX 控制台里线程池名全一样，分不清是谁的
复杂点在于：路由切换和事务、线程、连接池监控这四层不是正交的，动其中一层，另外三层都可能悄悄错位。最容易被忽略的是异步场景下的 ThreadLocal 遗漏清理，以及 Druid 监控路径的手动绑定——这两处不查日志根本看不出问题。
