RPC远程调用需结构化错误处理：统一结果体含success、code、message、errorTrace字段；服务端分层捕获异常并映射业务错误码；客户端按code分支处理，禁用异常类型判断；跨服务错误码须集中定义与语义对齐。
RPC 远程调用中异常信息不能裸传、不能吞掉、更不能只靠 getMessage() 交差。核心目标是：服务端能精准记录问题，客户端能明确失败原因，业务层能区分可重试/需告警/应提示用户。
统一结果包装体必须携带结构化错误字段
服务端返回类型（如 BaseResultDto<T>）需强制包含以下字段：
-
success：布尔值，标识整体调用是否成功（
true表示业务逻辑正常完成） -
code：字符串或整型错误码（如
"USER_NOT_FOUND"或4001），稳定、可枚举、不随环境变化 - message：面向前端或用户的简明提示（如“用户不存在”），不含敏感信息和堆栈细节
-
errorTrace：仅在
success == false时填充的完整异常堆栈字符串，供服务端日志与运维排查使用
服务端异常拦截要分层处理，不全抛也不全吞
服务端 Controller 或 Provider 实现中，需用 try-catch(Throwable) 兜底所有可能异常（包括 NoClassDefFoundError 等 Error）：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 捕获后，提取原始异常的
getClass().getName()、getMessage()和getStackTrace()，拼接为errorTrace - 根据异常类型映射业务错误码：比如
DuplicateKeyException→"ORDER_DUPLICATE_SUBMIT"，IllegalArgumentException→"PARAM_INVALID" - 避免直接返回
e.toString()或e.getMessage()，防止泄露数据库表名、路径、内部类名等敏感内容
客户端必须校验 success 并按 code 分支处理
Consumer 调用后，禁止直接解包 result 或判空，必须先检查 success：
立即学习“Java免费学习笔记（深入）”；
- 若为
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时降级为通用错误提示，避免因新增码导致客户端崩溃
