SQLException 是 checked exception，因数据库操作天然不可靠，JDBC 规范强制处理以避免静默失败；它不自动触发回滚，需显式调用 rollback() 或配置 Spring 的 rollbackFor。
SQLException 是检查异常，不是设计失误，而是 JDBC 为强制你面对数据库不确定性而设的“安全锁”。
为什么 SQLException 必须是 checked exception？
Java 异常体系里，SQLException 继承自 Exception 而非 RuntimeException，意味着编译器强制你处理它——要么 try-catch，要么 throws。这不是历史包袱甩不掉，而是 JDBC 规范（JSR-114）早期就定下的契约：数据库操作天然不可靠（网络中断、死锁、权限不足、约束冲突……），不能让你“假装没发生”。
比如执行一条 INSERT，可能因主键重复抛出 SQLState="23000"，也可能因连接断开抛出 SQLState="08S01"，这两类错误的应对策略完全不同：前者要提示用户改数据，后者要重试或降级。强制声明，就是逼你在代码路径里显式分叉。
- 不处理
SQLException→ 编译失败 → 避免上线后因未捕获连接异常导致服务静默失败 - Spring 默认不回滚
SQLException→ 正是因为它是 checked exception，框架假设你会自己判断并决策（重试？告警？回滚？） - 如果它是 runtime exception，大量 DAO 方法会“侥幸”不加保护，事务一致性立刻失控
SQLException 和事务回滚之间没有自动绑定关系
很多人以为“抛了 SQLException 就等于事务回滚了”，这是最危险的误解。JDBC 层面，SQLException 只是通知你出错了；是否回滚，完全取决于你有没有在 catch 块里调用 connection.rollback()，且该 Connection 当前处于 active transaction 状态。
- 默认
autoCommit = true：每条 SQL 单独提交，SQLException抛出时前一条已落库，回滚无意义 - 手动关了
autoCommit却忘了rollback()→ 数据库卡在中间状态，连接池可能回收连接但事务未清理 → 后续报"The transaction is no longer active - status: 'Marked rollback'" - Spring 中加了
@Transactional但没写rollbackFor = SQLException.class→SQLException被 catch 吞掉或仅 log，事务照常提交
真实项目里怎么接住 SQLException 并合理回滚？
别只写 e.printStackTrace()，那等于把日志当摆设。关键是要从异常里榨出可操作信息，并匹配动作：
- 先看
e.getSQLState()："08S01"（连接中断）、"40001"（死锁）→ 可重试；"23000"（唯一冲突）、"42000"（语法错）→ 不该重试，应业务拦截 - 再查
e.getErrorCode()：MySQL 的1205、PostgreSQL 的40001，比 SQLState 更准，适配具体数据库行为 - 记录完整上下文：SQL 原文 + 参数列表 +
getSQLState()+getErrorCode()，否则排查时只能猜 - 回滚前必判状态：
if (!conn.isClosed() && !conn.getAutoCommit()) { conn.rollback(); }，避免调用rollback()报"No transaction in progress"
真正难的不是写 try-catch，是在分布式、连接池、Spring 代理、多数据源混用的场景下，搞清“此刻事务归谁管、能不能滚、滚了有没有效”。一个 SQLException 抛出来，背后可能是网络层断连、数据库锁表、连接池超时、Spring 事务传播失效……它从来不只是个异常，而是一张问题定位地图的起点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
