将受检异常包装为有业务语义的运行时异常，旨在表达业务意图、厘清dao/service职责边界、支撑系统演进；dao层统一转化sqlexception等为dataaccessexception或自定义persistenceexception，service层专注业务逻辑与基于异常类型的重试/降级决策，禁止裸throw runtimeexception，须按场景归类封装（如invalidrequestexception、externalserviceexception），提供cause构造器并记录完整堆栈，辅以全局异常处理器与可观测性建设。
把受检异常包装成运行时异常，不是为了躲编译检查，而是让异常真正表达业务意图、理清各层职责、支撑系统持续演进。
在 DAO 与 Service 边界做一次干净剥离
旧代码常让 SQLException、IOException 直接穿透到 Controller，方法签名堆满 throws，业务逻辑被技术细节干扰。重构关键一步是划定“异常转化区”：
- DAO 层（或 MyBatis Mapper 实现类）统一捕获底层 IO/SQL 异常，转为语义明确的运行时异常，比如 Spring 的 DataAccessException，或自定义 PersistenceException
- Service 层方法不再声明 throws SQLException 等，只关注业务规则；重试、降级等决策也基于运行时异常类型，而非原始异常类名
- 禁止在 Service 内部 catch 再 throw 原始受检异常——这等于把技术细节重新塞回业务逻辑
用带业务含义的运行时异常替代泛型 RuntimeException
throw new RuntimeException(e) 虽能过编译，但会丢失所有可维护性。应按失败场景归类封装：
- 参数解析失败（如 JSON 反序列化错误、日期格式不匹配）→ IllegalArgumentException 子类，例如 InvalidRequestException
- 外部服务不可用或超时 → ExternalServiceException，携带服务名、超时阈值等上下文字段
- 状态不一致（如订单已支付却尝试取消）→ IllegalStateException 子类，例如 IllegalOrderStateException
- 所有自定义异常必须提供 Throwable cause 构造器，并在日志中记录原始异常类名和消息
为 Stream、CompletableFuture 等现代 API 提供安全适配
受检异常会直接卡住 lambda 表达式。不要每个地方都写 try-catch，而是轻量封装：
- 对 Files.readAllLines()、BufferedReader.lines() 等标准 IO 方法，优先使用 Java 8+ 内置的 UncheckedIOException 包装
- 对自定义 IO 逻辑，提供工具方法如 IOFunctions.unchecked(Files::readAllLines)，内部完成 try-catch + UncheckedIOException 构造
- 工具方法返回 Function
> 这类无异常声明的接口，保持流式操作简洁
配套全局处理器与可观测性补全链路
包装为运行时异常后，问题定位能力不能下降。必须同步落地支撑机制：
- 统一用 @ControllerAdvice 或 @ExceptionHandler 拦截 BusinessException 及其子类，返回结构化错误响应
- 所有异常在抛出前打点埋标，记录异常分类、触发路径、重试次数等维度，接入监控告警
- 日志中保留完整堆栈，确保原始异常 cause 和当前层包装异常同时可见，支持逐层下钻排查
