多数据源切换异常捕获需分层识别来源、明确上下文、隔离事务影响：连接异常查配置网络，sql异常核注解匹配，驱动异常做方言适配；aop增强异常携带数据源标识；只读操作禁用事务；启动校验连通性，路由失败返503，租户解析失败抛业务异常。

多数据源切换时异常捕获不能只靠通用 try-catch，关键在于分层识别异常来源、明确数据源上下文、隔离事务影响。否则容易把连接失败、SQL语法错误、跨库事务回滚失败混为一谈，导致问题定位困难。

区分异常类型与数据源归属

不同数据源抛出的异常虽同属 SQLException，但根因差异大，需结合数据源标识做针对性处理：

• 连接类异常（如 CommunicationsException、SQLException with SQLState = "08S01"）：说明目标数据源不可达，应检查该数据源配置、网络、账号权限，而非重试业务逻辑
• SQL执行类异常（如 SQLSyntaxErrorException、MySQLIntegrityConstraintViolationException）：说明语句在当前库不兼容（比如从库执行了 INSERT），需确认注解标注是否与操作类型匹配（@DS("slave") 不该出现在写方法上）
• 驱动/方言异常（如 PostgreSQL 的 PSQLException 或达梦的 SQLException with vendorCode=20001）：提示当前数据源类型与 SQL 写法冲突，需按库做方言适配或统一抽象

在异常堆栈中保留数据源上下文

默认的 SQLException 不含当前使用的数据源名称，需手动增强。推荐在 AOP 切面中捕获并包装：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 在 @Around 拦截数据库操作前，记录当前数据源 key：DataSourceContextHolder.getDataSourceKey()
• 若发生异常，在 catch 块中用自定义异常包装，附带数据源标识：new DataSourceAwareSQLException(e, "slave")
• 日志输出时统一打印：[DS:slave] SQLException: Duplicate entry 'xxx' for key 'uk_name'

避免事务干扰导致异常掩盖

@Transactional 与数据源切换共存时，异常行为易被误导：

• 若方法加了 @Transactional 且未指定 transactionManager，Spring 默认使用 @Primary 数据源的事务管理器 —— 即使你切到了 slave，事务仍绑定 master 连接，异常可能表现为“无法在只读连接上提交”
• 跨数据源操作（如先写 master 再查 slave）不在同一事务内，slave 查询失败不会触发 master 回滚，需显式判断并人工补偿
• 建议对只读操作（如 @DS("slave")）禁用事务：@Transactional(propagation = Propagation.NOT_SUPPORTED)，避免事务管理器干扰连接选择

针对常见场景的捕获建议

不是所有异常都要捕获，重点守住三类边界：

• 启动阶段：校验所有配置的数据源能否连通（如 HealthIndicator 中调用 getConnection().close()），失败直接阻断启动，不依赖运行时异常兜底
• 查询路由失败：当 determineCurrentLookupKey() 返回 null 或非法 key，AbstractRoutingDataSource 抛出 IllegalStateException，应在全局异常处理器中拦截并返回 503 Service Unavailable
• 租户/动态库名解析失败：如根据 tenantId 查库名返回空，应抛出明确业务异常（如 TenantDatabaseNotFoundException），而非让后续空指针或连接失败掩盖真实问题

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南