java接口不引发多继承异常冲突，真正冲突源于类实现多个接口或继承父类时方法契约的受检异常交集不可满足；实现类必须声明所有超类型要求的异常交集，否则编译失败。
Java接口本身不构成“多继承”异常冲突的源头，因为接口不抛异常——异常声明只出现在方法签名中，而接口方法若声明了受检异常（throws IOException），其约束力体现在实现类重写时，而非接口之间。真正的冲突发生在类同时实现多个接口（或继承父类+实现接口）且这些超类型对同一方法提出不同受检异常要求时。核心不是接口“多继承异常”，而是方法契约交集不可满足导致的编译失败。
接口方法声明受检异常后，实现类必须取最严格子集
当多个接口定义同名同参方法，并各自声明不同受检异常时，实现类不能简单“合并”或“忽略”，而必须提供一个兼容所有接口契约的声明：
- 若接口A声明
throws IOException，接口B声明throws SQLException，二者无继承关系 → 实现类无法合法声明任一异常，编译报错；必须重构：统一异常基类（如都声明throws DataAccessException），或拆分方法职责 - 若接口A声明
throws Exception，接口B声明throws IOException→ 实现类可声明throws IOException（它是Exception的子类，属于交集） - 若某接口声明
throws IOException，而父类对应方法未声明任何受检异常 → 实现类不能省略该 throws，必须至少声明IOException或其子类（接口契约优先于父类“无异常”声明）
与父类共存时，异常声明必须是交集，且父类无声明则接口强制生效
类继承父类并实现接口，同名方法的受检异常声明必须同时满足两者约束：
- 父类方法声明
throws IOException，接口方法声明throws FileNotFoundException（后者是前者的子类）→ 实现类可声明throws FileNotFoundException - 父类方法声明
throws IOException，接口方法声明throws SQLException→ 无共同子类，编译失败；这是设计缺陷信号，需用统一异常包装（如自定义DataAccessException统一继承RuntimeException）或调整分层职责 - 父类方法未声明任何受检异常，接口方法声明
throws IOException→ 实现类必须显式声明该异常或其子类，不可省略；否则破坏接口契约
函数式接口场景：受检异常需主动适配，不能绕过
JDK标准函数式接口（Function、Consumer 等）方法签名不含 throws，因此 Lambda 中调用可能抛受检异常的方法会直接编译失败：
- 错误写法：
list.forEach(s -> Files.readString(Paths.get(s)))→Files.readString()抛IOException，但Consumer.accept()不允许 - 正确做法：定义自己的函数式接口，如
ThrowingConsumer<t e extends throwable></t>，明确带throws E；再通过工具方法（如catching(() -> ...)）将其安全转为标准接口，把受检异常转为RuntimeException包装或返回Try<t></t>结果 - 关键点：这不是规避规则，而是将异常处理逻辑显式提升到类型系统层面，保持调用方代码整洁且类型安全
运行时异常完全自由，是解耦和简化契约的实用选择
RuntimeException 及其子类（IllegalArgumentException、NullPointerException 等）不受上述任何限制：
- 接口方法可自由声明
throws IllegalArgumentException，实现类可改抛IllegalStateException或干脆不声明 - 在数据访问、业务校验等场景，将原本的受检异常（如
SQLException、IOException）包装为运行时异常（如 Spring 的DataAccessException层次），能显著降低调用方的异常处理负担，同时不牺牲语义表达 - 只要团队约定清晰、日志完备、监控到位，用运行时异常替代部分受检异常是成熟项目的常见实践
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
