getcause()必须递归调用才能定位根因——因框架常嵌套3–5层异常，单次调用易停在中间层；需防循环引用、空指针与深度失控，推荐exceptionutils.getrootcause或三重防护手动遍历。
多层嵌套异常链中，getCause() 是唯一能逐层下钻、逼近真实故障点的入口——但只调一次没用，必须递归遍历，直到找到那个没被包装、真正触发问题的原始异常。
为什么单次 getCause() 容易误判
ShardingSphere、Spring Cloud、Feign 等框架常把异常包 3–5 层：外层是业务异常（如 BusinessException），中间是框架异常（如 ShardingSphereSQLException），内层才是驱动级错误（如 MySQLTimeoutException 或 ConnectException）。只取第一层 cause，很可能停在“中间层”，仍不是根因。
- 例如：
e.getCause()返回ShardingException，它的getCause()才是CommunicationsException - 又如：
TransactionSystemException的 cause 是 null，真实异常藏在getOriginalException()里，需特殊处理 - 某些自定义异常未显式传入 cause 构造，或用了默认构造器，调用
getCause()直接返回 null
安全可靠的递归遍历方式
手动 while 循环虽简单，但需防循环引用、深度失控和空指针。推荐两种做法：
- 用 Apache Commons Lang 的
ExceptionUtils.getRootCause(e)—— 内置 IdentityHashSet 去重、默认深度上限 16、自动跳过 null - 自己实现时加三重防护：判空 + 计数限深（建议 ≤10）+ 检查是否已见过该 Throwable 实例
- 不要依赖
e.printStackTrace()默认输出——它虽展示 “Caused by”，但对超长链或日志截断不友好；生产环境应提取 root cause 类型 + 消息 + 关键栈帧（如第 0 行）结构化记录
结合 getStackTrace 定位“谁干的”和“在哪干的”
拿到 root cause 后，别忘了它自带一份独立调用栈：rootCause.getStackTrace() 才反映真实出错位置。比如：
- 外层
RuntimeException的栈可能只到ReflectiveMethodInvocation.invoke() - 而 root cause
SocketTimeoutException的栈顶是OkHttpClient.newCall()或JdbcClient.execute() - 日志中建议组合输出：
[RootCause: java.net.SocketTimeoutException: timeout] → at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:257)
匹配错误码与分层归因的关键逻辑
定位 root cause 不是为了“看到报错”，而是为了“决定怎么响应”。逐层匹配错误码的本质是：让最懂这一层语义的模块来定性问题。
- 驱动层异常（如 MySQLTimeoutException）→ 映射为「数据库连接超时」，触发重试
- 分片逻辑异常（如 NoRouteTableException）→ 映射为「分库路由失败」，需告警+人工介入
- 业务校验异常（如 IllegalArgumentException）→ 映射为「参数非法」，直接返回客户端
- 匹配策略应从 root cause 开始向上扫描，一旦某层规则命中即终止，避免越往下语义越模糊
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
