编译器强制处理受检异常是java类型系统与字节码规范施加的静态约束，体现在编译期对方法签名和调用链的双向校验：javac在ast遍历阶段检查未捕获或未声明的受检异常（如ioexception），并将其写入字节码exceptions属性；调用链中每层方法必须显式throws或try-catch，直至main方法；而runtimeexception子类被jvm规范定义为逻辑缺陷信号，不参与该机制。
编译器强制处理受检异常，不是语法糖或风格建议，而是 Java 类型系统与字节码规范共同施加的静态约束。它的底层机制体现在编译期对方法签名和调用链的双向校验上。
编译期类型检查：异常声明即契约
Java 编译器（javac）在生成字节码前，会严格分析每个方法体中所有可能抛出的 受检异常类型（即 Exception 的子类，且非 RuntimeException 及其子类）。一旦发现某行代码可能抛出 IOException、SQLException 等，而当前方法既没有用 try-catch 捕获，也没有在 throws 子句中显式声明，编译器就判定该方法违反了“异常传播契约”，直接报错终止编译。
- 这个检查发生在 AST（抽象语法树）遍历阶段，不依赖运行时环境
- throws 声明会被写入字节码的
Exceptions属性，成为 JVM 加载方法时可读的元信息 - 调用方在编译时必须看到这个属性，并据此决定是捕获还是继续向上声明
调用链传导：异常必须有明确的“出口”
受检异常无法被“静默吞掉”。编译器要求从抛出处开始，每一层调用方法都必须参与异常处理决策：
- 如果 A 方法调用了可能抛出 IOException 的 B 方法，而 A 没有 catch，就必须在自己的 signature 中 throws IOException
- 这个 throws 会继续向上传导，直到某一层选择用 try-catch 处理，或到达 public static void main（此时未处理则编译失败）
- 这种传导是单向、不可绕过的，本质是编译器对“控制流完整性”的静态保障
与非受检异常的本质区别
RuntimeException 及其子类被排除在该机制之外，原因在于 JVM 规范将它们定义为“程序逻辑缺陷的信号”，而非外部环境导致的可预期失败：
- NullPointerException、IllegalArgumentException 等不进入字节码的 Exceptions 属性
- 编译器不追踪它们的抛出路径，也不校验调用链是否声明或捕获
- 它们的处理交由运行时或统一异常处理器（如 Spring 的 @ControllerAdvice），属于动态策略而非编译约束
这不是限制，而是接口语义的固化
强制声明受检异常，实质是把“该操作可能因外部因素失败”这一事实，编码进方法签名本身：
- 调用者无需阅读文档或源码，仅看方法声明就能知道需要应对哪些外部不确定性
- IDE 能基于 throws 信息自动提示 try/catch 补全
- API 设计者借此明确划清“业务主流程”和“环境交互副路径”的边界
