java不建议在业务逻辑中大量使用受检异常，因其将可预期的业务分支（如余额不足）误判为意外故障，破坏控制流清晰性、加重调用方负担并导致跨语言/架构适配失败，推荐以运行时异常配合统一响应体处理。
Java不建议在业务逻辑中大量使用受检异常（Checked Exception），核心原因是它会强行把**可预期的业务分支**混同于**真正的意外故障**，破坏代码清晰性、增加维护成本，并带来跨语言和架构适配问题。
破坏控制流清晰性
受检异常强制调用方用 try-catch 或 throws 声明，但很多业务失败根本不是“意外”——比如“余额不足”“用户已存在”“订单状态不允许操作”。这些是正常业务规则判断的结果，本该用 if 判断 + 返回值（如 Result
加重调用方负担且易被绕过
- 每个抛出点都得写 throws，每层都要决定是吞掉、转译还是继续上抛，开发效率明显下降
- 实际中常出现“catch 后 throw new RuntimeException(e)”这种反模式，等于废掉了编译检查的设计初衷
- 一旦绕过，就失去强制处理的意义，还让团队误以为“已兜底”，反而更难发现遗漏
不利于分层架构与跨系统协作
HTTP API、RPC 接口（如 Dubbo/Feign）、消息驱动场景中，受检异常无法自然传递：
- Spring MVC 默认不传播受检异常到 @ExceptionHandler，需额外适配
- Dubbo 等框架序列化时会丢弃受检异常类型，只保留 message 和 cause，语义全失
- 前端或异构语言客户端无法识别 Java 的受检/非受检语义，统一靠 HTTP 状态码 + error code 通信
替代方案更轻量、更可控
推荐用运行时异常（如 BusinessException）配合统一响应体：
- 构造时传入 ErrorCode 枚举（含状态码、提示语、是否可重试等元信息）
- 全局 @ControllerAdvice 捕获并转为标准 JSON 响应（如 {code: 2001, msg: "余额不足", data: null}）
- 关键业务字段（orderId、userId）直接作为异常成员变量，便于日志提取和监控聚合
真正需要受检异常的场景其实很少：外部资源强依赖且必须显式恢复（如文件写入失败后需人工介入、支付回调超时需定时重推）。其余绝大多数业务拒绝，都不是“系统出错了”，只是“流程走到另一条路了”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
