Java中不能仅靠getCause()判断网络超时，需结合异常类型（如SocketTimeoutException）、递归getRootCause()、消息关键词及配置上下文综合识别。
Java中不能直接靠getCause()判断异常是否由网络超时引起，因为超时本身不是独立异常类型，而是具体异常的**触发原因或根本原因（cause）**，需结合异常类型、消息、堆栈及上下文综合识别。
看异常类型：优先检查是否为已知超时相关异常
常见网络超时会抛出以下典型异常，它们本身已表明超时性质，无需依赖getCause()：
-
SocketTimeoutException：最直接的超时信号，继承自IOException，表示读/连接超时（如HTTP客户端未在指定时间内收到响应）； -
ConnectException（含“Connection timed out”消息）：常因连接阶段超时导致，此时getCause()通常为null，应检查getMessage()； -
UnknownHostException或NoRouteToHostException：虽非严格超时，但可能出现在DNS解析或路由不可达的长时间等待后，需结合日志时间判断； -
第三方库异常：如OkHttp的
java.net.SocketTimeoutException: timeout、Feign的feign.RetryableException: Read timed out，其getCause()可能是SocketTimeoutException，但更推荐直接匹配异常类或消息。
用getCause()辅助追溯深层原因（仅当外层异常是包装类时）
当捕获到的是框架封装异常（如Spring的ResourceAccessException、Feign的RetryableException），其getCause()才可能指向原始超时异常：
- 调用
e.getCause()逐层获取，直到返回null或得到SocketTimeoutException等目标类型； - 避免只查一级
getCause()——有些异常链长达3–4层（例如：RetryableException→IOException→SocketTimeoutException）； - 推荐用工具方法递归提取根本原因：
public static Throwable getRootCause(Throwable t) {
Throwable cause = t.getCause();
return (cause == null || cause == t) ? t : getRootCause(cause);
}
// 使用示例：
if (getRootCause(e) instanceof SocketTimeoutException) {
// 处理超时逻辑
}
别忽略异常消息和上下文信息
仅靠类型或getCause()可能误判。务必结合：
立即学习“Java免费学习笔记（深入）”；
- 异常消息中的关键词：如“timeout”、“timed out”、“Read timed out”、“connect timed out”，大小写不敏感匹配更稳妥；
-
调用方配置：确认HTTP客户端（OkHttp、Apache HttpClient）、数据库连接池（HikariCP）、RPC框架（Dubbo、gRPC）是否设置了合理的
connectTimeout和readTimeout； - 日志时间戳与超时阈值对比：若请求耗时 ≈ 设置的超时时间（如10s），再结合异常类型，基本可确认为超时；
-
排除其他干扰：如
SocketException: Connection reset是连接被对方关闭，非超时；IOException: Broken pipe属写入失败，也不代表超时。
实际判断建议（简洁可靠）
生产环境推荐组合判断，而非单靠getCause()：
- 先用
instanceof检查是否为SocketTimeoutException、ConnectException等明确超时类； - 再对包装异常调用递归
getRootCause()，检查结果类型； - 最后用
getMessage().toLowerCase().contains("timeout")兜底（注意避免误匹配如“timeout=30”这类配置字符串）； - 关键服务建议统一封装超时判定工具类，并记录原始异常全类名+消息，便于后续排查。
