Java中checked异常适用于调用方能且应主动处理的预期外部故障，如IOException、SQLException；不适用于逻辑错误、系统错误或无法干预的第三方异常，现代实践倾向减少使用。
Java中使用checked异常（受检异常）的核心原则是：当某个异常情况预期可能发生、调用方有能力且应当主动处理，并且不处理就编译不通过时，才定义为checked异常。
需要调用方显式决策恢复策略的场景
这类异常代表外部环境导致的、程序逻辑无法完全规避的问题，调用者必须考虑“怎么应对”，而不是忽略。
- 文件读写失败（red">IOException）：磁盘满、权限不足、路径不存在——调用方可能重试、换路径、提示用户或记录日志
- 网络连接异常（SQLException、MalformedURLException）：数据库宕机、URL格式错误——调用方可能降级、返回默认值或抛出业务异常封装
- 类加载失败（ClassNotFoundException）：动态加载类时类名拼错或jar未引入——调用方需明确是否允许失败、是否有备用类
业务契约要求强制处理的流程性异常
在框架或API设计中，用checked异常表达“这一步失败了，你必须明确响应”，形成清晰的调用契约。
- Spring事务中声明TransactionRequiredException（虽然它实际是unchecked，但对比说明：若设计为checked，则调用方必须catch或throws，避免无事务执行关键操作）
- 自定义支付接口抛出InsufficientBalanceException extends Exception：余额不足不是bug，是常见业务状态，调用方应跳转充值页而非崩溃
- 解析配置文件时抛出InvalidConfigurationException：配置错误应在启动时暴露，不允许静默忽略
不适用checked异常的典型情况
这些情况即使编译器允许，也不应强行用checked异常：
立即学习“Java免费学习笔记（深入）”；
- 程序逻辑错误（空指针、数组越界、类型转换失败）——属于RuntimeException，应修复代码，而非让调用方处理
- 系统级不可恢复错误（内存溢出、栈溢出）——JVM层面问题，捕获无意义
- 第三方SDK内部异常被过度包装成checked——增加调用负担，且调用方通常无力干预（如把HttpClient底层IO异常直接暴露给业务层）
- 所有分支都只是打印日志+忽略——说明本就不该是checked，而是用unchecked或直接返回错误码
现代实践中的谨慎倾向
从Java 7起，try-with-resources和多异常捕获简化了checked异常处理，但业界更倾向减少其使用：
