数据库连接超时异常需穿透包装定位根源，通过递归遍历getCause()链（最多5层），按类型、父类、消息匹配优先级获取真实错误码，并在全局异常处理器中统一解析，结合连接池配置与Feign重试实现多层防护。
数据库连接超时异常（如 MySQL 的 CommunicationsException、Oracle 的 SQLTimeoutException 或通用的 SQLException 子类）通常不会直接暴露在 Controller 层，而是被层层包装为业务异常或运行时异常。只靠顶层 @ExceptionHandler(Exception.class) 捕获，往往拿不到真正原因——比如你看到的是 BusinessException(code=500, msg="下单失败")，但实际该重试或告警的，是底层那个“Connection refused”或“Socket timeout”。所以捕获的关键不是“抓最外层”，而是“穿透包装，定位根源”。
用异常链逐级匹配真实错误码
Java 异常支持 getCause() 链式嵌套，数据库超时异常常藏在第 2–3 层。推荐构建一个可复用的 递归 Cause 匹配器，而不是写一堆 if (e instanceof SQLException) {...} else if (e.getCause() instanceof SQLException) {...}：
- 从 Controller 抛出的原始异常开始，调用
getCause()向下遍历，最多 5 层（防循环引用和栈溢出） - 对每一层，按优先级尝试匹配：精确类型（如
MySQLTimeoutException）→ 父类泛匹配（如所有SQLException子类统一映射为DB_TIMEOUT）→ 自定义谓词（如message.contains("timeout") || message.contains("connect timed out")） - 一旦某层匹配成功，立即返回对应错误码（如
"DB_CONN_TIMEOUT"），不再继续向下——实现“谁最清楚问题，谁定错误码”
在 GlobalExceptionHandler 中集成 Cause 解析
不要把解析逻辑散落在每个 @ExceptionHandler 方法里。建议封装成工具方法，在全局处理器中统一调用：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 定义一个
ErrorCodeResolver.resolve(Throwable e)，内部使用IdentityHashMap记录已访问异常实例，避免框架自引用（如某些 ORM 会把自身设为 cause） - 在处理
BusinessException或RuntimeException时，先调用它获取真实错误码，再决定是否重试、降级或告警 - 示例：
if ("DB_CONN_TIMEOUT".equals(resolver.resolve(e))) { return CommonResult.error(503, "服务暂时不可用，请稍后重试"); }
配合连接池与 Feign 调用做前置兜底
数据库连接超时往往也出现在远程调用场景（如 FeignClient 查询下游 DB 服务）。这时单靠后端异常处理器不够，需多层防护：
立即学习“Java免费学习笔记（深入）”；
- 数据库连接池（如 HikariCP）配置
connection-timeout和validation-timeout，并开启connection-test-query，让超时在连接获取阶段就暴露 - FeignClient 添加
@Retryable(value = {SQLException.class}, maxAttempts = 2)，但注意：仅对明确抛出SQLException的情况有效；若被包装成FeignException，仍需靠上面的 Cause 解析还原 - 日志中打印完整 cause 链（
log.error("DB timeout detected", e)），确保 ELK 或 Arthas 能查到原始堆栈，而非只有 “nested exception is xxx”
避免常见误操作
很多团队踩过这些坑，导致超时异常始终无法精准识别：
- 在 Service 层用
try-catch(SQLException e)吞掉后重新 thrownew BusinessException("操作失败")—— 这样原始异常信息彻底丢失 - 全局处理器只捕获
Exception.class，却没检查e.getCause()，结果所有 DB 超时都返回 500，无法区分是网络抖动还是服务宕机 - 忽略虚拟线程场景：若用
Thread.ofVirtual()执行 DB 操作，未设置uncaughtExceptionHandler，超时异常可能静默终止，连日志都不打
