TransactionSystemException是Spring事务系统级非受检异常，本质为包装类，真实原因藏于getCause()中；需重点排查底层cause（如CannotCreateTransactionException、ConstraintViolationException等）、事务传播配置、资源连接及ORM映射问题。
TransactionSystemException 是 Spring 框架中定义的 非受检异常（RuntimeException），属于事务基础设施层的系统级异常，通常不反映业务逻辑错误，而是暴露了事务管理本身的故障。它本身是包装类，真正原因藏在 cause 中——排查关键不是处理它，而是找到并修复底层触发它的根本问题。
看根因：必须打印并分析 getCause()
TransactionSystemException 自身信息有限，直接 catch 它而不检查 cause 会错过真实线索：
- 日志中务必输出
e.getCause() != null ? e.getCause().toString() : "no cause" - 常见 cause 类型：
CannotCreateTransactionException（数据源/连接失败）、TransactionTimedOutException（超时）、HeuristicCompletionException（JTA 分布式事务异常）、PersistenceException或具体 JPA 异常（如ConstraintViolationException） - IDE 调试时，展开异常对象，重点查看
cause字段及其堆栈
查事务传播与嵌套：REQUIRES_NEW 或 NESTED 易引发边界问题
当方法 A（REQUIRED）调用方法 B（REQUIRES_NEW），B 内部异常若未被捕获，会导致 B 的事务回滚，但 A 的事务可能继续执行——此时若 A 后续操作依赖 B 的写入，就可能触发数据一致性异常，最终被包装为 TransactionSystemException：
- 检查 @Transactional 注解的
propagation和rollbackFor配置是否合理 - 避免在 REQUIRES_NEW 方法内抛出未声明 rollbackFor 的自定义异常（默认只对 RuntimeException 回滚）
- NESTED 需数据库支持保存点（如 MySQL InnoDB），否则降级为 REQUIRED，可能掩盖预期行为
验资源与配置：连接泄漏、隔离级别冲突、平台事务管理器失效
事务系统异常常源于底层资源不可用或配置错位：
立即学习“Java免费学习笔记（深入）”；
- 数据库连接池耗尽（如 HikariCP 中
connection-timeout触发CannotCreateTransactionException）→ 查活跃连接数、慢 SQL、未关闭的 EntityManager/Session - 事务隔离级别不被数据库支持（如 MySQL 不支持 SERIALIZABLE 在某些引擎下）→ 导致事务开启失败
- 误配 PlatformTransactionManager（如用了 JpaTransactionManager 却操作 JDBC 模块，或多个事务管理器 Bean 未指定 primary）
- @EnableTransactionManagement 缺失或 proxy-target-class=false 时 CGLIB 代理失效，导致 @Transactional 失效，后续事务操作无上下文而报错
盯 ORM 层异常：JPA/Hibernate 异常被静默包装
JPA 操作失败（如主键冲突、外键约束、乐观锁失败）通常先抛出 javax.persistence.OptimisticLockException 等标准异常，Spring 事务拦截器捕获后统一包装为 TransactionSystemException：
- 开启 Hibernate 日志：
logging.level.org.hibernate.SQL=DEBUG和logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE，确认 SQL 是否真执行失败 - 检查实体映射（@Version 字段类型是否为 Long/Integer、是否缺失 @Column(updatable = false) 等细节）
- 批量操作中个别实体校验失败（如 @NotNull 字段为空），可能触发 ConstraintViolationException → 被包装，需结合 Bean Validation 日志定位
核心思路始终是：把它当一个“告警信封”，撕开它，读里面的原始异常，再顺着那个异常反推资源、配置、代码逻辑哪一环断了。不复杂但容易忽略。
