Java统一包装受检异常的核心是边界封装、语义建模与全局收敛：在适配层将SQLException等转化为自定义RuntimeException，用轻量异常承载业务语义并保留cause链，再通过@ControllerAdvice标准化响应。
Java中统一包装受检异常，核心不是绕过编译检查，而是把技术细节收拢到边界、把业务意图显性化、让错误可追溯可干预。关键在三层动作：边界封装、语义建模、全局收敛。
在适配层完成受检→非受检的干净转化
数据库、HTTP客户端、文件IO等第三方组件抛出的受检异常（如 SQLException、IOException、FeignException），不能穿透到业务层。必须在明确的边界做一次封装：
- DAO 层捕获 SQLException → 包装为 DataAccessException 或自定义 PersistenceException，附带 errorCode（如 DB_002）和 traceId
- Feign Client 捕获 FeignException → 包装为 RemoteServiceException.paymentTimeout(e)，标注下游服务名与超时值
- IO 工具类调用 Files.readAllLines() → 直接用 UncheckedIOException 包装，或封装成 ioFunction 工具方法供 Stream 安全使用
- 禁止在 Service 方法里写 try-catch-throw new RuntimeException(e) —— 这等于把底层细节重新暴露给业务逻辑
用轻量、可识别的自定义异常承载业务语义
所有自定义异常应继承 RuntimeException，只提供两个构造器：String message 和 String message + Throwable cause。其他字段（如 errorCode、context map）不参与异常链传递，仅用于响应构造或日志补充：
- 参数校验失败 → InvalidRequestException（IllegalArgumentException 子类）
- 外部服务不可达 → ExternalServiceException（含 serviceId、timeoutMs）
- 状态非法（如已支付订单再取消）→ IllegalOrderStateException（IllegalStateException 子类）
- 构造时必须传入原始异常：new PaymentProcessingException("订单 #ORD-20260607-8892 支付失败", e)，确保 getCause() 可逐层追溯
- 禁用 addSuppressed() 替代 cause —— suppressed 仅用于资源关闭失败等辅助异常，主路径必须走 cause 链
通过 @ControllerAdvice 实现链路级收敛与响应标准化
全局异常处理器不处理异常，只负责解析、映射与输出。它依赖异常链完整性和类型语义，才能精准响应：
- @ControllerAdvice 中按类型分层拦截：先 BusinessException，再 RemoteServiceException，最后兜底 RuntimeException
- 每个 @ExceptionHandler 方法中调用 logger.error("xxx", e)，而非 logger.error("xxx")，否则 cause 不会输出
- 递归遍历 e.getCause() 找最原始异常类型，提取 errorCode 并映射 HTTP 状态码（如 SecurityException → 403，DataAccessException → 500）
- 响应体固定结构：code、message、requestId、timestamp；若链中含审计类异常，自动触发落库动作
- 不捕获 Exception 类型作为兜底 —— 会吞掉 OutOfMemoryError、BeanCreationException 等本该暴露的严重问题
这套机制真正起效的前提，是每层都守住“封装边界”和“因果锚定”。异常不是数据容器，是语义信标；链不是补救手段，是主动设计的传播契约。
