受检异常与依赖倒置原则存在实现层面张力，核心在于接口是否将异常纳入契约：应避免接口声明技术异常（如sqlexception），改用自定义运行时异常（如dataaccessexception）封装，并通过optional等返回值替代非严重异常，以保持抽象稳定、解耦细节。
受检异常（Checked Exception）和依赖倒置原则（DIP）在 Java 实际设计中确实存在张力，但不是本质冲突，而是实现层面的协调问题——关键在于抽象接口的设计是否把异常也纳入契约考量。
受检异常会暴露实现细节
Java 的受检异常要求调用方必须显式处理或声明抛出。如果一个接口方法声明 throws SQLException 或 IOException，它就隐含绑定了数据库访问或 I/O 操作这类低层细节。这违背 DIP 的“抽象不应依赖细节”原则：高层模块（如 Service）因接口强制而不得不感知并适配底层技术栈的异常类型。
- 例如：
public User loadUser(int id) throws SQLException—— 接口直接泄露了 SQL 实现，后续换成 NoSQL 就得改接口，破坏抽象稳定性 - 这种设计让抽象（接口）反而依赖了细节（JDBC 异常体系），违反 DIP 第二条
解决方案：用运行时异常封装受检异常
保持接口干净、稳定，同时不丢失错误语义，推荐在抽象层统一使用自定义运行时异常（RuntimeException 子类），由具体实现负责转换：
- 定义业务异常，如
UserNotFoundException、DataAccessException（继承 RuntimeException） - 接口方法只声明业务语义异常，不暴露技术栈：
User loadUser(int id) throws UserNotFoundException - 具体实现（如 JdbcUserRepository）内部捕获 SQLException，再包装成
DataAccessException抛出 - 这样高层模块只依赖业务异常抽象，不耦合 JDBC 或文件系统等细节
依赖注入时异常处理要解耦
当通过 DI 容器注入实现类时，异常传播路径应保持透明。避免在构造器或 setter 中抛出受检异常（如初始化失败时 throw IOException），否则高层模块被迫处理底层初始化细节。
- 推荐将初始化逻辑延迟到首次调用，或封装为可选的
initialize()方法，并用运行时异常报告失败 - Spring 等框架默认支持运行时异常驱动的生命周期管理，与 DIP 更兼容
- 若必须在构造阶段验证（如配置缺失），可用
IllegalArgumentException等运行时异常替代 IOException
协议优先：用返回值代替异常表达结果
对非严重错误（如查询无结果、参数校验失败），可考虑用 Optional<user></user>、Result<t e></t>（如 Vavr 或自定义）替代异常，进一步弱化调用方对异常类型的依赖。
- 接口变成：
Optional<user> findUserById(int id)</user>，完全不抛异常 - 调用方按业务逻辑分支处理，而非 try-catch 技术异常
- 既符合 DIP（接口无异常签名），也提升可读性与组合性
