java中受检异常与非受检异常的核心区别在于编译器是否强制处理：前者继承exception但不继承runtimeexception（如ioexception），必须try-catch或throws；后者继承runtimeexception或error（如nullpointerexception、outofmemoryerror），编译器不检查，运行时才抛出。
Java 中受检异常和非受检异常的核心区别在于编译器是否强制你处理它，而不是它们抛出时的行为或性能表现。处理方式也由此自然分化：一个必须显式应对，另一个靠主动预防更有效。
看继承关系就能快速分辨
判断一个异常是否受检，最可靠的方式是查它的继承链：
- 如果它直接或间接继承 Exception，但没经过 RuntimeException（比如
IOException、SQLException、InterruptedException），就是受检异常 - 如果它继承 RuntimeException（如
NullPointerException、IllegalArgumentException）或 Error（如OutOfMemoryError），就属于非受检异常 - IDE 里按住 Ctrl 点击异常类名，看
extends那一行；Javadoc 中明确标有 “Checked exception” 的，也一定是受检的
编译器态度截然不同
这个差异直接影响你能不能把代码编译过去：
- 对受检异常，javac 会严格拦截：调用了可能抛出它的方法，又没
try-catch，也没在方法签名写throws，就会报错，例如unreported exception IOException; must be caught or declared - 对非受检异常，编译器完全不干预——哪怕你明知道某行会空指针，
obj.toString()照样编译通过；但它一旦运行时发生，程序立刻中断，堆栈打印出来 - 注意：lambda 表达式里不能声明
throws，所以像Files.readAllBytes()这类抛受检异常的方法，直接用在forEach里会编译失败，需要包装或换用支持异常的函数式接口
处理思路要匹配问题性质
不是所有异常都适合 catch，关键看它代表什么：
- 受检异常多对应外部可恢复场景：文件读不到、网络超时、数据库连不上。这时应选择重试、提示用户、降级或记录日志，而不是简单吞掉
- 非受检异常多反映内部逻辑缺陷：参数非法、状态不一致、空值误用。这类问题靠
if校验、Optional、断言提前拦截，比 try-catch 更高效也更清晰 - 自定义业务异常时，若希望调用方必须响应（如支付失败需引导重试），继承
Exception；若是校验失败等本该由开发者修复的问题，继承RuntimeException更合适
避开几个典型误区
实际编码中容易踩坑的地方：
- 把受检异常用
throw new RuntimeException(e)包一层来绕过编译检查——等于丢掉了“这事能恢复”的语义，后续排查和运维成本会明显上升 -
@Transactional方法里捕获了受检异常却没重新抛出，事务默认不会回滚（Spring 只对RuntimeException和Error回滚） - 用异常控制流程，比如靠
FileNotFoundException判断文件是否存在——应该改用Files.exists()，既快又语义准确
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
