在多层嵌套的异常链中，getCause() 是唯一能够逐层深入、逐步逼近真实故障点的入口——然而，仅调用一次往往毫无意义，必须采用递归遍历的方式，持续剥离每一层包装，直至找到那个未被封装、真正触发问题的原始异常。主流框架通常会将异常包裹三到五层，若只停留在中间层，依然难以看清根本原因。
为什么单次 getCause() 容易误判
像 ShardingSphere、Spring Cloud、Feign 这类框架，经常将异常层层嵌套：外层可能是业务异常（如 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 开始向上扫描，一旦某层规则命中即终止，避免越往下语义越模糊
