yii2不支持真正的嵌套事务，其所谓“嵌套”仅为逻辑调用，底层始终是单连接单事务模型；重复调用begintransaction()返回同一transaction实例，所有sql操作共享同一事务上下文，内层rollback会全局回滚或导致状态异常。
Yii2 本身不支持真正的嵌套事务（即数据库层面的 savepoint 嵌套），所谓“嵌套”只是逻辑上的调用关系，底层始终是单事务模型：内层事务操作实际加入外层已开启的事务，没有独立事务上下文，因此内层回滚无法局部生效，更无法控制外层行为。
Yii2 的事务本质是单连接单事务
Yii2 使用 yii\db\Transaction 封装数据库连接的 beginTransaction()、commit() 和 rollback()。关键点在于：
- 一个数据库连接（
Connection）在任意时刻最多只持有一个活跃事务对象； - 重复调用
$db->beginTransaction()不会创建新事务，而是返回当前已存在的Transaction实例（源码中通过$this->_transaction缓存）； - 所有 SQL 操作都绑定到该连接的同一事务上下文中，无论由哪个方法发起。
内层“回滚”实际只是提前标记或无效操作
如果你在内层手动调用 $transaction->rollback()，会出现两种典型情况：
-
外层尚未 commit，且内层 rollback 是第一个回滚调用：它会真正执行 SQL 的
ROLLBACK，整个事务终止，外层后续的commit()将失败（PDO 抛异常）； - 外层已 commit 或内层 rollback 被忽略（如未捕获异常继续执行）：由于 Yii2 不维护保存点（savepoint），也没有事务状态同步机制，内层 rollback 不会改变外层对事务的判断逻辑——外层仍按原计划 commit，但此时数据库连接可能已处于非法状态，导致不可预知错误。
与 Spring NESTED 的根本区别
Spring 的 Propagation.NESTED 依赖 JDBC Savepoint API，在同一个物理事务内设标记点，回滚仅退回到该点。而 Yii2：
- 不自动创建 savepoint；
- 无
rollbackToSavepoint()封装； - 开发者需手动用原生 SQL 执行
SAVEPOINT sp1和ROLLBACK TO SAVEPOINT sp1，且必须确保在同一个连接、同一事务生命周期内完成，否则无效。
为什么看起来像“内层不影响外层”？
常见误解源于错误写法，例如：
- 内层使用了独立数据库连接（如 new Connection()），那它和外层根本不在同一事务中——这不是嵌套，是并行事务；
- 内层 try-catch 吞异常但没 rollback，外层仍正常 commit：此时“内层没影响”是因为它压根没触发回滚，而非实现了局部回滚；
- 业务误将“异步消息补偿”“本地事件”等最终一致性手段当作嵌套事务能力。
简言之，Yii2 没有事务嵌套语义，只有事务参与。想实现类似效果，必须显式管理 savepoint 或改用最终一致性方案。
