rpc异常需用getcause()逐层解包获取根因，推荐用exceptionutils.getrootcause()或循环调用；服务端须透传cause链，日志应记录完整嵌套异常以保留上下文。
在rpc远程调用中，异常往往被层层包装（如 remoteexception、executionexception、自定义的 rpcexception），原始异常信息被隐藏，直接打印堆栈只能看到外层包装，无法定位真实错误根源。java 的 getcause() 方法是还原真实异常的关键——它能逐层解包，直达最内层的根本原因。
理解 getCause() 的链式结构
RPC异常通常是“异常嵌套”：服务端抛出原始异常 → 序列化/传输过程包装为通信异常 → 客户端反序列化后再次包装为调用异常。每层都通过构造函数将上层异常设为 cause。调用 getCause() 就是沿着这条因果链向上追溯。
- 不是所有异常都有 cause：只有通过带
Throwable cause参数的构造器创建的异常才持有 cause -
getCause()返回null表示已到根因，或该异常未设置 cause - 推荐用
ThrowableUtils.getRootCause()（Apache Commons Lang）或手动循环调用getCause()，避免只调一次就止步
在客户端统一解包并打印真实堆栈
捕获 RPC 异常后，不要直接 e.printStackTrace()，而是先提取 root cause 再输出：
try {
result = rpcService.doSomething();
} catch (Exception e) {
Throwable root = e;
while (root.getCause() != null) {
root = root.getCause();
}
System.err.println("真实异常: " + root.getClass().getSimpleName());
System.err.println("错误消息: " + root.getMessage());
root.printStackTrace(); // 打印真实堆栈
}
也可借助工具类简化：Throwable root = ExceptionUtils.getRootCause(e);（需引入 commons-lang3）
服务端主动透传原始异常信息
很多 RPC 框架（如 Dubbo、gRPC、Spring Cloud OpenFeign）默认会截断或模糊化服务端异常。要确保客户端能拿到完整 cause 链，需服务端配合：
- Dubbo：配置
dubbo.provider.filter=exception并确保异常未被全局拦截器吞掉；自定义ExceptionFilter时，不要吃掉原始异常的 cause - gRPC：服务端应将业务异常转为
StatusRuntimeException，并通过Status.withCause()显式携带原始异常 - 自研 RPC：序列化异常对象时，必须递归序列化
cause字段，不能只序列化最外层异常的 message 和 stackTrace
日志记录时保留完整异常上下文
仅控制台打印不够，生产环境依赖日志排查。使用 SLF4J 时，直接传入 root cause 可能丢失外层上下文（如 RPC 调用路径）。更稳妥的方式是：
- 记录完整嵌套异常：
log.error("RPC调用失败", e);—— 大部分日志框架（Logback、Log4j2）会自动展开 cause 链 - 若需结构化日志，可手动构建异常摘要：
"Root: " + root.getClass().getSimpleName() + ", Message: " + root.getMessage() - 关键字段（如 traceId、method、url）务必和异常日志同行输出，便于关联定位
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
