受检异常是接口语义的一部分，显式声明外部依赖边界；非受检异常守护内部逻辑自洽，二者分工协作构成分层防御。
受检异常不是语法负担，而是对代码逻辑边界的显式声明。它把“这个操作依赖外部状态”这件事，从隐含假设变成方法签名里可读、可追踪的契约。
受检异常即接口语义的一部分
当你写 public String readConfig() throws IOException，这行签名本身就说明：该方法的行为不完全由输入参数决定，还取决于文件系统是否就绪、路径是否存在、权限是否足够。这不是缺陷，而是事实——而受检异常强制你把它写进契约里。
- 调用方看到
throws IOException，立刻知道要准备应对磁盘或权限问题，而不是等运行时才发现配置加载失败 - IDE 能基于 throws 提示补全 try-catch，文档生成工具能自动提取异常说明，API 设计因此更透明
- 如果改成
throw new RuntimeException(e)绕过检查，等于主动抹掉这个语义，后续排查时只能靠日志猜“是不是文件没读到”
非受检异常反映内部逻辑断言
NullPointerException 或 IllegalArgumentException 出现，通常意味着某个前提条件被违反了——比如传入了 null 但方法契约本应要求非空。这类问题不该靠 try-catch 处理，而该靠提前校验或重构逻辑来杜绝。
-
if (obj == null) throw new IllegalArgumentException("obj must not be null")比 catch NPE 更清晰 - 单元测试应覆盖这些边界，让问题在开发阶段暴露，而不是留到生产环境崩溃
- 全局异常处理器可以兜底记录，但不能替代代码层面对逻辑前提的主动声明
二者共同构成分层防御
受检异常守住“与外界交互”的边界，非受检异常守住“内部逻辑自洽”的底线。它们不是对立关系，而是分工协作：
- 底层工具类（如文件读取、HTTP 请求）用受检异常暴露外部不确定性
- 业务服务层用非受检异常快速失败，避免把错误状态传递下去
- Controller 层统一捕获两类异常，但处理方式不同：受检异常转成用户可理解的提示，非受检异常记录堆栈并返回 500
误用会破坏契约可信度
把受检异常吞掉、包装成 RuntimeException、或在 lambda 里无视它，表面是省事，实际是在削弱代码的可推理性。
-
catch (IOException e) { }让调用方误以为“一定成功”，结果数据静默丢失 - 在 Stream.forEach 中调用 Files.readAllBytes，编译不过——这不是 API 设计缺陷，而是提醒你：批量 IO 操作需要集中处理异常，而非逐条忽略
- 强行用 try-catch 包裹所有可能抛出 NullPointerException 的地方，反而掩盖了真正该修复的空值来源
