关键在于递归提取SQLException的根异常，精准识别SocketTimeoutException或ConnectException等网络超时原因，并按读/写/初始化等场景分层实施缓存降级、异步重试或默认值返回，避免对权限错误、语法错误或连接池耗尽等问题误降级。
数据库连接超时不是“连不上”那么简单，它背后可能是网络抖动、DB负载过高或连接池配置不合理。关键在于：要捕获到真实的超时根源，并让降级策略只对这类可恢复问题生效，而不是把语法错误、权限不足也一并兜底。
捕获真正的连接超时异常
Java中JDBC连接超时通常抛出的是SQLException，但它的根因往往是SocketTimeoutException或ConnectException——这些被包装在SQLException的cause链里。直接判断ex instanceof SQLException不够，必须递归提取根异常：
- 用工具方法安全获取根因（避免空指针和循环引用）：
public static Throwable getRootCause(Throwable t) {<br> Throwable root = t;<br> while (root.getCause() != null && root.getCause() != root) {<br> root = root.getCause();<br> }<br> return root;<br>}
- 检查根因是否属于网络类超时：
getRootCause(ex) instanceof SocketTimeoutException || getRootCause(ex) instanceof ConnectException - 注意区分：SQLState为"08S01"（通信链路失败）或错误码如MySQL的1042/1043，也是连接超时的强信号
分层设计降级动作，不一刀切
连接超时本身不等于业务失败，降级策略要按场景细化：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 读操作（如查询用户信息）→ 触发缓存 fallback 或返回上次有效快照
- 写操作（如下单）→ 记录本地消息队列，异步重试；同时返回“处理中，请稍后查看”
- 初始化阶段连接失败 → 启动时加载默认配置，记录warn日志，允许服务带降级状态上线
- 非关键查询超时 → 直接返回空集合或默认值，不告警，仅trace日志
在实际代码中嵌入降级逻辑
推荐在DAO层或数据访问模板中统一拦截，而不是每个方法都写try-catch：
- 使用Spring的
@Repository+@ExceptionHandler配合自定义异常处理器，集中识别根因并转发降级 - 若用MyBatis，可在
Configuration.setVfsImpl()前注册拦截器，在Executor.query()抛异常时介入 - 手动创建Connection时，设置超时参数并捕获异常：
conn = DriverManager.getConnection(url, props);<br>// 或更安全地用HikariCP等连接池，配置connection-timeout=3000
- 捕获后立即执行降级，不继续执行后续SQL逻辑
- 记录带上下文的日志，例如：“[order-query] DB connect timeout after 3000ms, fallback to redis cache”
避免常见陷阱
很多团队把降级做成了掩盖问题的“创可贴”，要注意：
- 不要在catch里吞掉异常又不记录——至少warn级别+堆栈
- 不要对所有SQLException都fallback，默认值只适用于明确可接受的超时场景
- 连接池耗尽（如HikariCP的Connection acquisition failed）不是连接超时，而是资源瓶颈，该扩容或限流，不该降级
- 超时时间设置要合理：connectTimeout一般设1~3秒，比业务整体超时短；避免设成30秒导致线程长时间阻塞
