受检异常的本质是将外部不确定性转化为方法签名中不可绕过的编译期契约。它强制调用方显式决策如何应对可预期的外部失败（如IO、网络、配置问题），而非掩盖或忽略；要求异常类型精确、传播路径清晰，并限于应用层守门，避免污染领域模型。

受检异常对调用者的约束力，本质是把“外部不确定性”变成方法签名里不可绕过的契约条款。它不靠文档提醒、不靠团队约定，而是由编译器在代码写完那一刻就强制校验：你调用了这个方法，就必须面对它可能失败的事实。

方法签名即风险说明书

当一个方法声明 throws IOException，它就不再是“可能会出错”，而是明确告诉调用者：“我依赖文件系统，而文件系统可能不可用——你得决定怎么应对”。这种声明直接写入字节码的 Exceptions 属性，IDE 能高亮未处理路径，编译器会在调用处报错，连 main 方法都逃不掉。

• 调用方不能假装没看见：不 try-catch，就必须在自己方法上 throws 向上传导
• 异常类型不可模糊替换：若父接口声明 throws SQLException，实现类不能改成 throws Exception，否则编译失败
• 新增一个受检异常，等于给整条调用链加一道关卡——所有中间层都得同步更新签名，否则编译中断

约束力落在“必须决策”，而非“必须修复”

它不强制你当场解决问题，但强制你做出选择：重试？降级？记录并告警？还是继续推给上层？这种“决策可见性”让隐性失败无处藏身。比如物流系统中 reserveStock() 声明抛出 InsufficientStockException，调用方就不能只写个空 catch 吞掉，而必须显式写出 log.warn("库存不足，触发补货流程") 或 throw new OrderFulfillmentFailedException()。

• 静态检查确保每个分支都有出口，避免“逻辑断点”被跳过
• 异常类型越具体（如 PaymentTimeoutException 而非笼统的 Exception），调用方的决策粒度就越细
• 与全局异常处理器不冲突——后者处理的是兜底策略，而受检异常确保兜底策略已被显式纳入设计

约束力的边界：仅限可预期的外部失败

它不约束业务逻辑错误，比如传入负数重量、重复提交运单——这类问题属于领域规则，应由非受检的领域异常（如 InvalidWeightException）表达，保持测试轻量和模型干净。受检异常只锚定那些“代码没错，但环境不配合”的场景：网络抖动、服务宕机、磁盘满、配置缺失、第三方限流等。

• 领域层不抛受检异常，避免技术细节污染业务语义
• 应用层入口用受检异常守门，确保关键操作（如创建运单、扣减库存）的失败路径全部暴露
• 一旦越界使用（如在聚合根里 throw IOException），反而削弱约束力——因为开发者会习惯性用 try-catch 掩盖设计缺陷