遇到 PersistenceException 别急着 catch，先看它是不是包装异常
绝大多数 PersistenceException 是运行时抛出的包装类，本身不带具体原因——它只是 JPA 规范定义的顶层异常，真正的问题藏在 getCause() 里。直接捕获 PersistenceException 并打印堆栈，往往只看到一层空壳。
- 必须调用
e.getCause()向下挖，常见真实根因是SQLException、ConstraintViolationException或 Hibernate 自己的QueryTimeoutException - Spring Data JPA 环境下，更推荐捕获
DataAccessException子类（如DataIntegrityViolationException），它们已做语义化翻译，比原始PersistenceException更易判断 - 如果用原生
EntityManager，建议在 catch 块里加一行日志：log.error("PersistenceException root cause: {}", e.getCause(), e)
ConstraintViolationException 和数据库约束冲突怎么对应上
这个异常表面看是 JPA 抛的，实际源头永远在数据库 DDL：唯一索引、非空字段、外键约束被违反。但错误信息里通常不带具体字段名或表名，光看 ConstraintViolationException 很难定位。
- PostgreSQL 会把约束名塞进
SQLException.getSQLState()或getMessage()，例如"23505"（唯一违规）或"23502"（空值违规），可据此分支处理 - MySQL 的
SQLState更模糊，得靠解析getMessage()，常见关键词有"Duplicate entry"、"Cannot add or update a child row" - Hibernate 6+ 默认开启
hibernate.dialect.resolver，能自动映射约束名到实体字段；旧版本建议在实体上显式标注@Column(name = "email", unique = true)，方便事后回溯
事务边界内 PersistenceException 导致数据不一致的风险点
JPA 要求一旦 PersistenceException 抛出，EntityManager 进入“无法使用”状态，后续操作（包括 clear() 或新 persist()）都可能继续失败。很多人忽略这点，在 catch 里强行续写逻辑，结果事务没回滚干净，或二级缓存残留脏数据。
- 只要抛出
PersistenceException，当前事务必须标记为 rollback-only，Spring 下用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() - 不要在 catch 块里调用
entityManager.clear()或entityManager.close()——JPA 规范不保证此时状态安全 - 如果需要重试，必须新开 EntityManager（比如用
@Transactional(propagation = Propagation.REQUIRES_NEW)包裹补偿逻辑）
为什么 PersistenceException 在单元测试里总不出现
测试用 H2/HSQLDB 时，很多真实数据库约束（如外键级联、部分索引、检查约束）压根不生效，导致本该抛 PersistenceException 的场景静默通过，上线后才暴雷。
立即学习“Java免费学习笔记（深入）”；
- H2 默认兼容模式是
MYSQL或POSTGRESQL，但检查约束（CHECK）默认关闭，需显式加参数：jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;CHECK=TRUE - 外键约束在 H2 中默认启用，但级联行为（
ON DELETE CASCADE）需确认是否建表时声明了CONSTRAINT ... ON DELETE CASCADE，仅靠 JPA@OneToMany(cascade = CascadeType.REMOVE)不触发 DB 层级联 - 最稳妥的做法：集成测试连真实数据库（如 Testcontainer 启一个 PostgreSQL），否则约束类异常永远测不到
真正麻烦的不是异常类型本身，而是它背后混杂了 JDBC 层、方言实现、事务管理器、甚至数据库配置的多重影响。每次看到 PersistenceException，别先想怎么 catch，先查 getCause()、看 SQL 日志、核对数据库实际约束定义——漏掉任意一环，修复都是蒙的。
