DataAccessException 是 Spring 对 JPA 原生异常的统一包装结果，需通过 Spring 管理的 EntityManagerFactory 和事务代理才能触发转换，手动获取 EntityManager 或显式 flush 会绕过该机制，导致异常未被正确映射。
为什么 DataAccessException 不是直接抛出来的？
因为 JPA 规范本身不定义运行时异常体系，PersistenceException 及其子类（如 EntityExistsException）都是受检异常或未按 Spring 风格归类。Spring 的 DataAccessException 是抽象层统一包装的结果，不是 Hibernate 原生抛出的——它由 SessionFactoryUtils.convertJdbcAccessException 或更底层的 JpaVendorAdapter 转换而来。
常见错误现象：org.hibernate.exception.ConstraintViolationException 被捕获后，你以为能用 instanceof DataIntegrityViolationException 判断，结果为 false，因为没走 Spring 的转换流程。
- 必须启用 Spring 的 JPA 集成（比如用
LocalContainerEntityManagerFactoryBean，而非手动 newEntityManagerFactory） - 事务必须由
@Transactional或TransactionTemplate管理，否则异常不会被代理拦截和转换 - 自定义
EntityManager获取方式（如通过emf.createEntityManager()直接拿）会绕过转换链路
ConstraintViolationException 为何有时转成 DataIntegrityViolationException，有时又变成 UncategorizedSQLException？
转换结果取决于底层 JDBC 驱动返回的 SQLState 或错误码，以及 Spring 对该数据库厂商的适配精度。MySQL 和 PostgreSQL 的约束报错格式差异大，Hibernate 中间又做了一层封装，导致最终映射不稳定。
使用场景：你在 MySQL 上测试时捕获到 DataIntegrityViolationException，换到 H2 内存库就变成 UncategorizedSQLException，不是代码写错了，是 H2Dialect 没覆盖对应错误码映射。
- 检查你用的
spring-jdbc版本是否匹配数据库驱动（例如 MySQL 8.0+ 需要mysql-connector-java:8.0.33+） - 可通过重写
CustomSQLExceptionTranslator并注册到LocalContainerEntityManagerFactoryBean的jdbcExceptionTranslator属性来强制统一 -
ConstraintViolationException.getConstraintName()在某些方言下为空（如 HSQLDB），别依赖它做业务分支
手动调用 entityManager.flush() 时异常丢失转换怎么办？
这是最常踩的坑：flush() 抛的是原生 PersistenceException 子类，Spring 的异常转换器默认只拦截声明式事务边界内的操作（如 save()、delete()），而 flush() 是显式触发，不在代理方法列表里。
性能影响：有人为“确保报错及时”频繁调用 flush()，反而让异常脱离 Spring 统一处理，还增加 flush 次数，拖慢批量操作。
- 避免在事务方法内手动
flush()，除非你明确需要同步验证（比如校验唯一索引冲突并提前响应） - 如果必须 flush，用
try-catch捕获原生异常，再调用JdbcAccessor.translateException("flush", null, e)手动转换 - 注意
flush()后若再有变更，可能触发二次 flush，重复报错
自定义 Repository 方法里怎么稳定拿到 DataAccessException 子类？
Spring Data JPA 的 @Query 或派生查询默认走统一异常翻译，但如果你在 repository 方法里用了 @Modifying(clearAutomatically = true) + nativeQuery = true，部分数据库驱动（如 Oracle）会绕过 Hibernate 异常封装，直接抛 SQLException，导致 Spring 来不及转换。
参数差异：@Modifying(flushAutomatically = false) 不会触发 flush，也就不会触发异常转换链路；而 clearAutomatically = true 会清一级缓存并隐式 flush，才有机会进转换流程。
- 所有
@Modifying方法必须加@Transactional，否则 clear/flush 行为不可控 - 避免在 native query 中写违反方言的语法（如 MySQL 用
RETURNING），否则驱动直接 throw SQLException，跳过 Hibernate 层 - 测试时别只看 H2，用真实数据库跑一次集成测试，H2 的错误码模拟经常不全
转换逻辑藏得深，不是配个 @EnableJpaRepositories 就自动生效；真正起作用的是代理对象、事务管理器、方言实现、驱动行为四者咬合的结果。漏掉其中一环，异常就“裸奔”了。
