rpc远程调用需结构化错误处理：统一结果体含success、code、message、errortrace字段；服务端分层捕获异常并映射业务错误码；客户端按code分支处理，禁用异常类型判断；跨服务错误码须集中定义与语义对齐。

RPC 远程调用中异常信息不能裸传、不能吞掉、更不能只靠 getMessage() 交差。核心目标是：服务端能精准记录问题，客户端能明确失败原因，业务层能区分可重试/需告警/应提示用户。

统一结果包装体必须携带结构化错误字段

服务端返回类型（如 BaseResultDto<t></t>）需强制包含以下字段：

• success：布尔值，标识整体调用是否成功（true 表示业务逻辑正常完成）
• code：字符串或整型错误码（如 "USER_NOT_FOUND" 或 4001），稳定、可枚举、不随环境变化
• message：面向前端或用户的简明提示（如“用户不存在”），不含敏感信息和堆栈细节
• errorTrace：仅在 success == false 时填充的完整异常堆栈字符串，供服务端日志与运维排查使用

服务端异常拦截要分层处理，不全抛也不全吞

服务端 Controller 或 Provider 实现中，需用 try-catch(Throwable) 兜底所有可能异常（包括 NoClassDefFoundError 等 Error）：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 捕获后，提取原始异常的 getClass().getName()、getMessage() 和 getStackTrace()，拼接为 errorTrace
• 根据异常类型映射业务错误码：比如 DuplicateKeyException → "ORDER_DUPLICATE_SUBMIT"，IllegalArgumentException → "PARAM_INVALID"
• 避免直接返回 e.toString() 或 e.getMessage()，防止泄露数据库表名、路径、内部类名等敏感内容

客户端必须校验 success 并按 code 分支处理

Consumer 调用后，禁止直接解包 result 或判空，必须先检查 success：

• 若为 false，优先读取 code 做业务分流：如 "TIMEOUT" 触发重试，"AUTH_FAILED" 跳转登录，"SYSTEM_ERROR" 上报监控
• message 直接透传给前端展示；errorTrace 仅在 debug 日志级别写入本地日志，生产环境关闭输出
• 不依赖异常类型做判断——因为远程异常经序列化后，客户端很可能缺少对应 class，instanceof 会失效甚至引发 NoClassDefFoundError

跨服务错误码需集中定义与语义对齐

多个系统共用 RPC 接口时，错误码不能各自为政：

• 建立团队级 ErrorCode 枚举，每个项含 code、message、httpStatus 和可选 retryable 标识
• Provider 抛出异常时，统一构造 BusinessException(code)，由全局异常处理器填充响应体
• Consumer SDK 应内置 ErrorCode 映射表，当收到未知 code 时降级为通用错误提示，避免因新增码导致客户端崩溃

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南