ora-02083与spring的unexpectedrollbackexception本质是同一事务状态在不同层级的表现：oracle已将事务标记为rollback-only，spring在commit时发现该不可逆状态而抛异常；主因包括catch吞异常未rethrow、required嵌套调用内层抛异常、约束违反或ddl导致隐式回滚。
Oracle报错 ORA-02083 直接对应 Spring 的 UnexpectedRollbackException
Spring 报 org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only，底层往往就是 Oracle 抛了 ORA-02083。这不是两个独立问题，而是同一事务状态在不同层的体现：Oracle 已将当前事务标记为“只可回滚”，而 Spring 在 commit 阶段发现该状态不可逆，于是主动抛异常终止流程。
@Transactional 方法里 catch 了异常但没 rethrow
这是最常见、也最容易被忽略的触发点。Spring 的事务切面只在目标方法**向外抛出异常**时才触发回滚逻辑；如果方法内部用 try-catch 吞掉异常，事务代理并不知情，仍会尝试提交——但此时数据库连接（尤其 Oracle）早已因异常操作（如约束冲突、空指针触发的 JDBC 异常）将事务置为 rollback-only 状态。
- 错误写法：
catch (Exception e) { log.error(...); }—— 事务已坏，但代码继续跑 - 正确做法之一：在
catch块末尾加throw new RuntimeException(e) - 正确做法之二：手动标记回滚：
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() - 注意：
currentTransactionStatus()在非事务上下文会抛NoTransactionException，需先判空
PROPAGATION_REQUIRED 嵌套调用 + 内层抛异常
当 A 方法（@Transactional）调用 B 方法（同样 @Transactional(propagation = Propagation.REQUIRED)），两者共享同一物理事务。若 B 抛出未捕获异常，Spring 会立即将整个事务标记为 rollback-only；而 A 若捕获该异常并继续执行，最终 commit 时就会撞上这个状态。
- 典型场景：Webservice 接口里，外层做日志记录或消息发送，内层做 DB 操作
- 临时解法：
@Transactional(propagation = Propagation.REQUIRES_NEW)让内层用独立事务 —— 但要注意事务隔离和连接池压力 - 更稳妥方案：避免在事务方法中直接调用另一个
@Transactional方法，改用服务拆分或事件驱动 - Oracle 特别敏感：它的事务状态同步比 MySQL 更严格，
REQUIRES_NEW下子事务失败不会影响父事务，但父事务若后续再操作同一行数据，可能触发锁等待或死锁
Oracle 约束违反或 DDL 操作导致隐式回滚
Oracle 在遇到唯一键冲突、外键不匹配、NOT NULL 字段插 null 等情况时，会立即终止当前语句并回滚该语句级变更，同时将整个事务标记为 rollback-only。Spring 无法区分这是语句失败还是业务逻辑失败，只要 commit 时状态不对，就抛 UnexpectedRollbackException。
- 排查重点：检查 SQL 日志中是否有
ORA-00001、ORA-02291等错误码紧跟在事务开始之后 - 预防手段：在 insert/update 前加轻量级校验（如先查主键是否存在），而非依赖数据库报错兜底
- DDL 风险：Oracle 中执行
ALTER TABLE等隐式 commit 操作，会提前结束当前事务，后续所有操作都在新事务中 —— 此时 Spring 的事务代理完全失控
真正麻烦的不是报错本身，而是它总在“看起来没问题”的地方出现：异常被吞了、嵌套调用没注意传播行为、Oracle 约束比预想更严格。盯住 rollback-only 这个状态源头，比单纯 catch 异常更有价值。
