Yii 2.0 的 beginTransaction() 不支持真正嵌套事务，多次调用仅增加引用计数，不创建数据库 SAVEPOINT；外层 rollback 会导致全部回滚，需手动执行原生 SQL 管理保存点。
Yii 2.0 的 beginTransaction() 不支持真正嵌套事务
直接说结论：Yii 2.0 的 beginTransaction() 调用多次，底层只是对同一个 PDO 事务做引用计数，不是数据库层面的 SAVEPOINT 嵌套。一旦外层 rollback()，所有内层操作一并回滚，不存在“只回滚内层”的可能。
常见错误现象是写了个业务方法 A 调用方法 B，两个都写了 $transaction = $db->beginTransaction()，以为 B 回滚不影响 A —— 实际上只要 B 调用了 $transaction->rollback()，A 后续的 commit() 就会抛出 Exception: Trying to commit a transaction which is not active。
- Yii 2.0 默认不自动创建 SAVEPOINT，
beginTransaction()只是调用 PDO::beginTransaction() - 若需模拟嵌套，必须手动用
$transaction->getConnection()->createCommand('SAVEPOINT sp1')->execute() - 回滚到保存点要用原生 SQL：
$transaction->getConnection()->createCommand('ROLLBACK TO SAVEPOINT sp1')->execute() - 注意：MySQL 5.7+、PostgreSQL 支持 SAVEPOINT；SQLite 支持有限；SQL Server 需用
SAVE TRANSACTION语法
想安全实现“局部回滚”，得自己管 SAVEPOINT
Yii 2.0 没封装 SAVEPOINT 操作，但可以基于现有 Transaction 对象扩展逻辑。关键不是换框架，而是明确谁负责建点、谁负责回滚、谁负责释放。
使用场景典型如：订单创建（主事务）中调用积分扣减（可失败重试），你不希望积分失败导致整个订单失败。
- 在进入子逻辑前，手动执行
$transaction->getConnection()->createCommand("SAVEPOINT deduct_point")->execute() - 子逻辑出错时，不用
$transaction->rollback()，而是$transaction->getConnection()->createCommand("ROLLBACK TO SAVEPOINT deduct_point")->execute() - 成功后可选释放保存点：
$transaction->getConnection()->createCommand("RELEASE SAVEPOINT deduct_point")->execute()（非必需，事务结束自动清理） - 务必检查返回值或捕获异常，PDO 默认不报错，
execute()失败会静默返回false
Transaction 对象复用时，isActive 状态容易误判
很多人以为 $transaction->isActive 是“当前是否处于活动事务中”，其实它只表示该对象是否由 beginTransaction() 创建且尚未 commit() 或 rollback() —— 即使数据库连接已断开、事务早已被服务端强制终止，这个属性仍可能为 true。
典型坑：长事务 + 连接超时 + 异常未捕获 → 后续 $transaction->commit() 报 PDOException: There is no active transaction，但 $transaction->isActive 还是 true。
- 不要依赖
$transaction->isActive做流程控制，尤其在 try/catch 外围 - 每次
commit()或rollback()后，手动置空引用：$transaction = null - 高并发下，避免把
Transaction对象传给多个 service 方法共享，状态易混乱 - 调试时可用
$transaction->getConnection()->getActive()辅助判断连接是否还活着
升级 Yii 3 或改用更细粒度的事务管理库要慎重
Yii 3 确实内置了 savepoint() 和 rollBackTo() 方法，但升级成本不只是改几行代码：迁移过程中模型验证、AR 行为、查询构造器的事务感知逻辑都可能变化；而且很多老项目依赖的是 Yii 2.0 的 DB 组件定制（比如分库路由、SQL 日志钩子），这些在 Yii 3 中接口不兼容。
如果只是解决嵌套问题，比升级更轻量的做法是封装一个 NestedTransaction 工具类，统一处理 SAVEPOINT 的命名、嵌套深度、自动释放逻辑 —— 它不侵入原有 AR 流程，也能让团队形成一致约定。
最常被忽略的一点：事务边界和领域逻辑边界的错位。比如把“发短信”“写日志”塞进同一事务，看似原子，实则违反单一职责，也放大了锁表风险。SAVEPOINT 解决不了设计问题，只能兜底。
