关键在于让异常“会说话”且前后端使用同一套语义化语言：1. 定义带code/message/details的业务异常类；2. 设计含code/message/data的标准响应体；3. 用@RestControllerAdvice统一翻译异常；4. 前端通过拦截器按code自动处理，提升协作效率与用户体验。

关键在于让异常“会说话”，且前后端听的是同一套语言。业务异常不是错误日志，而是结构化的业务信号——它要能准确表达“哪里不对”“为什么不对”“前端该怎么反应”。下面从后端实现到前后端协同，分四步说清楚。

定义带语义的业务异常类

不直接 throw new RuntimeException("用户不存在")，而是封装成可识别、可分类、可扩展的对象：

• 继承 RuntimeException，避免强制 throws，保持业务代码干净
• 携带 code（字符串或整数）、message、可选 details（如失败字段名、资源 ID）
• 推荐用枚举统一管理 code，比如 UserErrorCode.NOT_FOUND、OrderErrorCode.OUT_OF_STOCK，避免硬编码和拼写错误
• 构造时 message 可支持占位符（如 "用户 {0} 未激活"），便于后续国际化或动态填充

设计前后端共约的响应体结构

响应体不是技术容器，而是协作契约。建议固定三字段核心结构：

• code：业务状态码（非 HTTP 状态码），如 "USER_LOCKED"、"PARAM_MISSING"，前端据此做精准跳转或提示
• message：面向用户的友好提示，后端按请求头 Accept-Language 动态翻译，不暴露技术细节
• data：仅用于成功响应；异常时设为 null 或省略，避免误导前端解析
• 可选补充：timestamp（便于排查）、requestId（链路追踪）、details（供前端展示上下文，如 { "field": "email", "reason": "格式不合法" }）

用全局异常处理器做“翻译中枢”

@RestControllerAdvice 不是兜底工具，而是协议转换器。它把各类异常“翻译”成标准响应体：

• 捕获自定义业务异常 → 映射为对应 code + message，HTTP 状态码通常用 400（客户端错）或 403/401（权限类）
• 捕获 @Valid 校验失败 → 提取第一个字段错误，转为 PARAM_VALIDATION_FAILED + 具体提示
• 捕获 NullPointerException 等系统异常 → 统一降级为 SYSTEM_ERROR，记录完整堆栈到日志，但响应中绝不返回 stackTrace
• 所有异常处理方法都返回统一的 Result>，确保 Controller 层无需关心异常格式

前端按约定自动消化异常信号

前端不该每个接口都手动 try-catch，而应建立拦截层统一响应：

• Axios 拦截器中检查 response.data.code，遇到已知码（如 TOKEN_EXPIRED）自动刷新 token 或跳登录页
• 对未知 code，上报监控平台并显示默认提示：“操作失败，请稍后重试”，不崩溃、不白屏
• 利用 details 字段增强交互，例如校验失败时高亮对应表单项，库存不足时禁用提交按钮
• 配合 HTTP 状态码做基础分流：4xx 提示用户操作问题，5xx 显示服务暂不可用，避免混淆业务逻辑与网络问题