持久层职责是准确暴露数据访问失败事实并保留原始上下文，只抛技术异常（如SQLException或DataAccessException子类），不抛业务异常，不使用initCause()封装业务语义——该职责属于服务层。
微服务持久层（如 DAO 或 Mapper 层）通常只应抛出或封装底层技术异常（如 SQLException、JDBCException），而不直接抛业务异常。因此，不推荐、也不应该在持久层用 initCause() 统一抛出业务异常。这不是设计职责，也违背分层原则和异常链最佳实践。
持久层的异常处理职责是什么
持久层的核心任务是：准确暴露数据访问失败的事实，并尽可能保留原始错误上下文。它不负责解释“为什么业务失败”，只负责回答“数据库/存储出了什么问题”。
- 应原样抛出受检的数据访问异常（如
SQLException），或包装为 Spring 的DataAccessException子类（如CannotAcquireLockException） - 避免在 DAO 中 new ServiceException、BusinessException 等业务异常
- 绝不调用
initCause()把技术异常“挂”到一个已构造好的业务异常上——因为该业务异常本不该出现在这一层
真正的统一出口在服务层（Service）
业务异常的统一包装和上下文增强，必须发生在服务层——那里才具备业务语义。例如：
- DAO 抛出
SQLException("Lock wait timeout") - Service 捕获后，创建新的
OrderException("下单失败：库存锁定超时", e) - 这个构造过程自动建立异常链，
e成为 cause，无需initCause()
为什么 initCause() 在持久层尤其危险
在 DAO 层强行使用 initCause()，往往意味着以下反模式：
立即学习“Java免费学习笔记（深入）”；
- 提前 new 出一个空业务异常（如
new BusinessException()），再试图补 cause —— message 和 cause 分离，易遗漏或错序 - 多个 DAO 方法共用同一异常实例，造成 cause 被重复设置，触发
IllegalStateException - 破坏 Spring 的事务回滚机制：Spring 默认只对
RuntimeException及其子类回滚，而手动构造+initCause 的异常可能未正确继承或声明
正确的分层异常链示例
以订单创建为例：
-
DAO 层：
throw new SQLException("Deadlock found"); -
Service 层：
throw new BusinessException("库存扣减失败", e);（e 即 SQLException） -
Controller 层：
throw new ApiException("ORDER_CREATE_FAILED", e);
每一层都用带 Throwable 参数的标准构造器包装，链路自然、安全、可追溯。JVM 和日志框架（如 Logback、Log4j2）能完整输出嵌套栈，IDE 也能逐层展开 cause。
