unexpectedrollbackexception源于数据库触发器内rollback导致事务被数据库层硬终结，spring提交时因事务已不可逆回滚而抛出该异常；根本解决方式是避免触发器执行rollback，改用signal/raise抛异常或前置业务校验。
触发器里执行 ROLLBACK 会直接终止当前事务上下文，Spring 无法再提交它，于是抛出 UnexpectedRollbackException
触发器内 ROLLBACK 与 Spring 事务状态冲突
数据库触发器（如 MySQL 的 BEFORE INSERT 或 PostgreSQL 的 TRIGGER）在执行时属于同一数据库会话和事务上下文。一旦触发器内部显式调用 ROLLBACK（或因错误隐式回滚），整个事务会被数据库标记为“已回滚”，后续任何 COMMIT 都会失败。
Spring 在方法末尾尝试 commit() 时，底层 JDBC 驱动收到的是 “Can't commit because transaction is rolled back” 类似错误，最终包装成 UnexpectedRollbackException 抛出。
- 这不是 Spring 主动回滚，而是数据库层已不可逆地终结了事务
- Spring 的事务管理器对此无感知——它只依赖 JDBC 连接的事务状态反馈
- 即使外层代码没抛异常、也没手动
setRollbackOnly()，也会报错
常见误用场景：用触发器替代业务逻辑校验
开发者有时在触发器中做业务规则检查（比如库存不足时 ROLLBACK），但没意识到这会破坏 Spring 的事务生命周期。
- 例如：订单插入前，库存触发器发现
stock 就 <code>ROLLBACK - Spring 事务方法正常走完，最后
commit()失败 → 报Transaction rolled back because it has been marked as rollback-only - 日志里看不到原始触发器错误，只看到 Spring 的包装异常
为什么 PROPAGATION_REQUIRES_NEW 也救不了
有人试图在外层方法加 @Transactional(propagation = Propagation.REQUIRES_NEW) 隔离事务，但无效：
- 触发器运行在同一个数据库连接上，共享同一事务 ID（MySQL）或同一顶层事务（PostgreSQL）
-
REQUIRES_NEW只影响 Spring 层的代理逻辑，不改变底层 JDBC 事务边界 - 触发器仍能感知并破坏外层事务状态，Spring 提交时照样失败
真正可行的修复方式
避免在触发器中执行 ROLLBACK；把控制权交还给应用层：
- 触发器改用
RAISE EXCEPTION（PostgreSQL）或SIGNAL SQLSTATE '45000'（MySQL 5.5+），让异常透出到 JDBC 层 - Spring 捕获该 SQL 异常后，按默认规则回滚（
RuntimeException触发 rollback），状态可控 - 或在业务方法中提前校验（如查库存），失败就抛
RuntimeException，不进 DB 层 - 若必须用触发器兜底，至少让它只写日志或发通知，别动事务状态
关键点在于：数据库层的 ROLLBACK 是硬终结，Spring 事务模型无法绕过它恢复——能做的只有不让它发生。
