transactionsystemexception 报错需先查 getcause()，90% 为 sqlexception 或 connectionclosedexception；常见原因包括连接池未校验连接有效性、本类方法调用导致事务失效、innodb 锁等待超时。
TransactionSystemException 报错时先看 cause，不是事务配置问题就是数据库连接已丢
这个异常本身是 Spring 的包装类，几乎不带有效信息。真正线索藏在 getCause() 里——90% 情况下是 SQLException 或 ConnectionClosedException。别急着改 @Transactional 注解，先打日志看嵌套异常：
log.error("TX failed", ex); // 确保打印完整堆栈，尤其 cause 那一层
常见触发场景：数据库主从切换、连接池超时回收、MySQL 服务重启后连接未重连。Spring 事务管理器不会自动重试失效连接。
检查 DataSource 连接池是否启用了 testOnBorrow 或 validationQuery
很多项目用 HikariCP 或 Druid 却没配连接有效性校验，导致事务开始时拿到的是已断开的连接。这不是 Spring 的锅，是连接池配置漏项：
- HikariCP 必须设
connection-test-query=SELECT 1（MySQL）或connection-test-query=SELECT 1 FROM DUAL（Oracle） - Druid 要开
test-on-borrow=true+validation-query=SELECT 1 - 别信
auto-commit=true能绕过问题——事务内它会被强制覆盖
@Transactional 方法里调用本类其他方法，事务会静默失效
这是最隐蔽的坑：A 方法加了 @Transactional，内部直接调用本类的 B 方法，而 B 方法也操作数据库。结果 B 的 DB 操作不在事务中，但 A 提交时发现数据不一致，抛 TransactionSystemException。
立即学习“Java免费学习笔记（深入）”；
原因：Spring 事务靠代理实现，本类方法调用不走代理。解决方式只有两个：
- 把 B 方法抽到另一个
@Service类里，通过接口注入调用 - 用
AopContext.currentProxy()强制走代理（仅限类代理模式，且需开启expose-proxy=true）
别写“我这没用代理”，只要用了 @Transactional 就一定依赖代理机制。
MySQL 的 innodb_lock_wait_timeout 被触发，报错却显示为 TransactionSystemException
当事务卡在行锁等待超时，MySQL 返回 Lock wait timeout exceeded，Spring 捕获后包装成 TransactionSystemException。此时查 cause 会看到 SQLState: 40001 和具体超时信息。
应对重点不是加大超时值，而是定位谁在持锁：
- 执行
SHOW ENGINE INNODB STATUS\G，看TRANSACTIONS部分的lock struct(s) - 检查是否有长事务没提交（比如忘记
commit的手动Connection） - 避免在事务里做 HTTP 调用、文件读写等耗时操作
事务边界越窄越好，别让数据库锁住业务逻辑的等待时间。
