java受检异常是编译期硬性约束，非语法糖：javac在ast阶段静态检查未捕获/未声明的exception子类（排除runtimeexception），强制调用链显式处理或声明，异常信息写入字节码exceptions属性，保障控制流完整性与接口语义明确性。
Java受检异常（Checked Exception）强制处理不是语法糖，而是编译期嵌入类型系统的硬性约束，根植于字节码规范和方法契约设计。
编译器在AST阶段就拦截未声明/未捕获的受检异常
javac解析源码生成抽象语法树（AST）时，会逐行扫描所有可能抛出受检异常的语句（如new FileInputStream()可能抛FileNotFoundException）。一旦发现该异常既没被try-catch包围，当前方法签名里又没用throws声明，编译器立即报错，不生成字节码。这个检查独立于运行环境，纯静态分析。
- 检查对象仅限Exception子类中排除RuntimeException及其子类的部分
- 异常类型信息会被写入字节码的Exceptions属性表，供JVM加载时读取
- IDE能据此提供自动补全、导航和错误提示，因为契约已固化在字节码元数据中
调用链必须形成显式异常出口，不能中断或隐匿
受检异常沿调用栈向上传导时，每一层方法都必须表态：要么自己catch，要么在throws中列出该异常。这个传导是单向且不可绕过的。
- 如果方法A调用了声明throws IOException的方法B，A就必须声明throws IOException或用try-catch处理
- 这个链条最终必须终止于某处的catch块，或到达main方法——若main也没处理，编译直接失败
- 它保障的是“控制流完整性”：每个可能失败的外部交互，其错误路径在编译期就已确定
与RuntimeException的本质分野在于JVM规范定义
RuntimeException及其子类被JVM规范明确定义为“程序逻辑缺陷信号”，不属于可预期的外部失败场景，因此被排除在编译约束之外。
- NullPointerException、ArrayIndexOutOfBoundsException等不写入字节码的Exceptions属性
- 编译器不追踪它们的抛出路径，也不校验调用方是否处理
- 这类异常交由运行时机制（如JVM指令check_null）触发，处理策略属于动态层面（如全局异常处理器）
强制不是为了限制，而是把“依赖外部”编码进接口
看到readFile(String path) throws IOException，你就知道这个方法不是纯计算，它触碰了文件系统。这种声明让接口语义更完整，和参数、返回值一样成为API的一部分。
- 没有throws的方法，调用方可默认它不依赖外部状态
- 有throws的方法，调用方立刻明白需准备应对策略（重试、降级、提示用户等）
- 团队协作中，异常流成了可读、可查、可推演的设计维度，而非隐藏风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
