核心是用业务状态码替代受检异常，通过统一响应结构（code/message/data）避免异常栈开销；http状态码仅表通信结果，业务码独立定义在响应体中；需配套规范文档、sdk自动解析和监控告警。
用业务状态码替代受检异常，核心不是“去掉异常”，而是把原本由 throws 强制抛出、JVM 层面捕获再包装的流程，转为统一返回结构中的字段（如 code、message），避免异常栈生成、频繁 try-catch 和调用链中断带来的开销。这对高频 RPC 调用的微服务尤其明显。
状态码要分层设计，不混用 HTTP 状态码和业务码
HTTP 状态码（如 200/400/500）只反映通信与协议层面结果；业务状态码（如 1001 用户不存在、2003 库存不足）应独立定义在响应体中。Spring Boot 常用方式是封装统一响应类：
public class Result<t> {
private int code; // 业务码，非 HTTP 状态码
private String message;
private T data;
// 构造方法略
}
</t>Controller 不 throw Exception，而是根据逻辑分支返回 Result.success() 或 Result.fail(1001, "用户未登录")。
受检异常该删就删，但别丢掉语义和可追溯性
像 SQLException、IOException 这类底层异常仍需捕获并转换，但不再向上抛出给业务层。关键点是：
- 服务内部用日志记录原始异常（含堆栈），保证可观测性
- 对外只暴露轻量、可预期的业务码，不泄露技术细节
- 所有业务错误路径都走同一返回结构，客户端无需区分“是异常还是正常响应”
例如用户注册失败，不 throw UserExistException extends Exception，而是：
- DAO 层捕获唯一约束异常 → 记录 warn 日志 + 提取错误原因
- Service 层判断为“用户名已存在” → 返回
Result.fail(3002, "用户名已被占用") - Controller 直接 return，无 try/catch 包裹
网关层统一拦截，把业务码映射成合适的 HTTP 状态码
前端或下游服务更习惯通过 HTTP 状态码做基础分流（如 4xx 重试、5xx 告警）。可在 API 网关（如 Spring Cloud Gateway）或统一过滤器中做映射：
-
code=0→ HTTP 200 -
code=10xx/20xx（参数/业务校验失败）→ HTTP 400 -
code=50xx（系统级失败，如 DB 不可用）→ HTTP 500
这样既保持 RESTful 感知能力，又不让业务逻辑耦合 HTTP 协议细节。
配套要做三件事，否则状态码只是换汤不换药
光改返回结构不够，必须同步落地：
- 建立业务码规范文档：按模块划分号段（如订单 4000–4999）、明确每个码的含义、触发条件、是否可重试
-
客户端 SDK 封装自动解析：Java SDK 或 JS SDK 接收到
code != 0时，自动抛出自定义运行时异常（如BusinessException），方便调用方处理，而非手动 if 判 code - 监控告警绑定业务码：ELK 或 Prometheus 中对高频非 0 code（如 3002 单日超 1000 次）设置阈值告警，替代原来对 Exception 类名的统计
状态码本身不提升性能，减少异常创建、避免 JVM 异常处理机制介入、降低序列化体积（无 stackTrace）、提升 GC 效率，这些才是真实收益来源。不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
