受检异常处理需嵌入系统级分层策略，按业务风险、恢复可能性与干预成本动态匹配处理路径：配置加载失败终止应用，用户交互io异常转友好提示，定时任务日志失败降级补偿；结合异常链传递上下文，分层拦截（接入层转标准响应、服务层抛业务异常、dao层转化领域异常），并配套错误码体系、治理看板与重试机制。
受检异常处理本身不直接构成“层次化管理”，但将其嵌入系统级的异常分层策略中，能显著提升健壮性和可维护性。关键在于：不是为异常分类而分层，而是按异常所代表的业务风险、恢复可能性与干预成本，动态匹配处理路径。
按业务影响划分响应层级
同一类受检异常（如 IOException）在不同上下文中应触发不同响应：
- 文件读取失败发生在配置加载阶段 → 视为启动失败，需终止应用并输出明确错误日志
- 用户上传附件时发生IO异常 → 属于可恢复交互场景，应捕获后转为友好的业务提示，并提供重试按钮
- 后台定时任务写日志失败 → 可降级为内存缓冲+异步补偿，不影响主流程，但需告警并记录失败次数
结合异常链构建上下文感知的处理流
单纯 throw/catch 不足以支撑分层。需利用异常的原因链（getCause()）和自定义字段传递上下文：
- 包装原始受检异常时，添加业务标识（如 operationType=“payment”、riskLevel=HIGH）
- 全局异常处理器根据 riskLevel 转发：HIGH → 推送至运维看板；MEDIUM → 记录审计日志；LOW → 仅记 trace 日志
- 避免在 service 层吞掉 IOException 后静默返回 null，这会切断异常传播链，使上层无法判断是空结果还是失败
用分层拦截替代扁平式 try-catch 堆砌
把异常处理逻辑从各 service 方法中抽离，按职责分层拦截：
- 接入层（Controller）：统一捕获受检异常，转换为标准错误响应体（含 error_code、message、trace_id），屏蔽技术细节
- 服务层（Service）：只抛出有意义的业务异常（如 InsufficientBalanceException），对底层 IOException 等做轻量封装或重试（最多2次）
- 数据访问层（DAO）：专注转化 JDBC/IO 异常为领域相关的受检异常（如 DataAccessException），不自行处理或记录
配套机制保障分层落地
分层策略若无支撑，易退化为纸面设计：
- 定义清晰的错误码体系，将受检异常类型映射到业务错误码（如 IO_FAIL → ERR_STORAGE_001），而非暴露 SQLException 这类技术码
- 建立异常治理看板，统计各层级捕获的受检异常类型、频次、平均处理耗时，识别高频失败点（如某外部 API 的 ConnectException 持续上升）
- 对可重试的受检异常（如网络超时、临时锁冲突），在 DAO 层集成断路器与指数退避，避免简单重复抛出
