企业级开发中应优先用运行时异常表达业务规则和内部错误，受检异常仅用于第三方SDK、金融强契约场景等少数情况；基础设施层封装原始异常为运行时异常，应用层抛业务运行时异常，网关层统一处理并返回标准响应。
在企业级开发中，受检异常（Checked Exception）与运行时异常（RuntimeException）的选型不是语法问题，而是设计契约问题：它决定了调用方是否必须显式处理、异常是否属于业务流程的一部分、以及系统能否清晰表达“可恢复”与“不可恢复”的边界。
明确异常分类的核心原则
Java 异常体系的设计初衷是让开发者区分两类问题：
- 受检异常：表示调用方合理预期可能遇到且有能力恢复的外部不确定性，比如文件不存在、网络超时、数据库连接失败。这类异常强制编译器介入，迫使调用链上某一层做决策（重试、降级、提示用户、记录并转为业务错误等）。
- 运行时异常：表示程序逻辑错误或不可恢复的内部状态异常，比如空指针、数组越界、参数非法（违反前置条件）、数据不一致。它们不强制捕获，应通过代码审查、单元测试和防御性编程提前规避，而非靠 try-catch 挽救。
企业项目中推荐的异常建模方式
避免直接抛出 IOException 或 SQLException 这类通用受检异常。应在领域层定义语义清晰的自定义异常，并按职责分层封装：
- 基础设施层（DAO/Client）：捕获原始受检异常（如
SQLException），转换为统一的、带上下文的运行时异常（如DataAccessException），不向上抛受检异常。这是 Spring 等主流框架的实践基础。 - 应用服务层（Service）：对业务规则校验失败（如“余额不足”、“订单已关闭”）抛出自定义的 运行时异常（如
InsufficientBalanceException）。这类异常本质是业务流的分支，不是意外，应由上层（如 Controller）统一捕获并转化为 HTTP 状态码或错误码。 - 网关/接口层（Controller/Api）：只处理最终面向调用方的异常。将所有异常（包括运行时异常）统一拦截，映射为标准响应体（如
{ "code": "BUSINESS_ERROR", "message": "库存不足" }），并控制是否记录堆栈（敏感信息不外泄）。
哪些场景仍需谨慎使用受检异常
并非完全弃用受检异常。在以下有限场景中，保留受检异常能强化契约、提升可维护性：
- 开放给第三方使用的 SDK 或公共 API 包，需要强制调用方意识到某些失败必须处理（如证书过期、配额超限）；
- 核心金融交易流程中，某些外部依赖（如支付网关回调确认）失败后，业务上必须人工介入或走补偿流程，此时用受检异常可防止开发者“静默忽略”；
- 遗留系统集成桥接层，需严格遵循老协议的错误语义，且调用方无法升级框架时，可封装为受检异常并附带清晰 Javadoc 说明恢复策略。
团队落地的关键配套措施
规范选型不能只靠约定，需工程化保障：
- 在代码检查工具（如 SonarQube、Checkstyle）中配置规则：禁止在 service 层 throws 原始 JDBC/IO 受检异常；禁止在 controller 层 catch RuntimeException 后吞掉或裸 throw；
- 建立团队共享的异常基类体系，例如：
BizException（运行时，用于业务规则）、SystemException（运行时，用于系统故障）、ExternalException（受检，仅限 SDK 或特定集成场景）； - 每个自定义异常必须有明确的文档说明：触发条件、是否可重试、建议恢复动作、是否需告警、是否计入监控指标。
