jdbc异常转换核心是将sqlexception转为语义清晰、分层合理、可追溯的业务或数据访问异常。应优先使用spring dataaccessexception体系，dao层转为领域异常，service层转为业务异常，保留cause链，避免裸jdbc，日志需完整输出异常链。
在 JDBC 中建立规范统一的异常转换机制，核心是**不直接暴露 SQLException，而是将其转化为语义清晰、分层合理、可追溯的业务或数据访问异常**。这不是简单包装，而是一套覆盖设计、实现、日志与集成的实践体系。
用 Spring 的 DataAccessException 体系替代裸 SQLException
Spring 提供了开箱即用的异常翻译能力，这是最推荐的起点：
- 所有基于 JdbcTemplate、NamedParameterJdbcTemplate 或 Spring Data JPA Repository 的操作，都会自动将原始 SQLException 转为
DataAccessException子类（如DuplicateKeyException、DataIntegrityViolationException、CannotAcquireLockException） - 这些子类是非检查型异常，无需强制 throws，且携带明确语义，上层 Service 可直接捕获并做业务响应
- 事务管理（
@Transactional）也依赖该体系判断是否回滚——若手动 catch SQLException 并忽略，事务会失效
自定义异常需分层、带上下文、保 cause
当 Spring 默认翻译不够贴合业务时，应在 DAO/Repository 层做二次转译：
- DAO 层：将
DataAccessException转为领域级数据异常，如UserNotFoundException、OrderDataCorruptedException - Service 层：进一步转为业务异常，如
InsufficientStockException、PaymentValidationFailedException，避免跨层越级捕获底层异常 - 每个自定义异常构造器必须支持
Throwable cause参数，并在调用时传入原始异常，确保根因不丢失 - 错误消息要包含关键业务上下文，例如：
"用户[ID:1024]状态非法，当前为'已注销'，无法执行激活操作"
避免裸 JDBC，杜绝手动解析 SQLState 或 errorCode
绕过 Spring 封装直接使用 DriverManager.getConnection() + Statement 是异常治理的最大破口：
- 不同数据库驱动返回的
SQLState（如 MySQL “23000” vs PostgreSQL “23505”）和errorCode含义不一致，手动 if-else 判定不可维护 - 容易遗漏
close()导致连接泄漏，或在 finally 块中吞掉二次异常 - 正确做法是统一通过
JdbcTemplate或DataSourceUtils.getConnection()获取连接，让 Spring 托管资源与异常生命周期
日志与监控必须穿透异常链
仅打印最外层异常会导致问题定位困难：
- 记录日志时使用
logger.error("查询用户失败", e)（SLF4J / Log4j 会自动展开 cause 链） - 禁止只写
e.getMessage()或e.toString()；禁止调用e.printStackTrace()（不走日志框架，无法配置） - 在告警或链路追踪系统中，应提取并上报
rootCause类型（如MySQLTimeoutException）和关键字段（sqlState=HY000,vendorCode=1205）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
