Yii 2.0.50 事务稳定性需靠显式 beginTransaction + forUpdate() 统一加锁顺序、设锁超时与重试、避免耗时操作及多表反向加锁，乐观锁无法解决读-改-写竞态。
Yii 2.0.50 中事务稳定性不只靠“加个 beginTransaction”，关键在控制锁行为、规避竞争窗口、统一资源访问顺序。线上高频场景（如秒杀、订单创建）一旦出现 ERROR 1213 (40001): Deadlock found，说明 MySQL 已主动截断事务——这不是异常，而是你设计没防住。
事务必须包裹 forUpdate()，否则锁无效
很多开发者写 Product::find()->where(['id'=>1])->forUpdate()->one() 就直接改库存，结果超卖。因为 forUpdate() 只是生成 SQL 标记，不开启事务，它根本不加锁。
- 正确写法：先
$transaction = Yii::$app->db->beginTransaction()，再调用forUpdate()，且所有读写操作必须在commit()前完成 - 避免在
forUpdate()后做耗时操作（如调外部接口、发邮件），否则锁持有时间拉长，死锁概率指数上升 - 批量锁定更高效：不要循环
findOne() + forUpdate()，应先查 ID 列表，再SELECT * FROM product WHERE id IN (1,2,3) FOR UPDATE
必须设锁等待超时并实现重试逻辑
Yii 默认不设 innodb_lock_wait_timeout，MySQL 使用默认 50 秒，高并发下容易堆积阻塞。PHP 层也不会自动捕获死锁错误重试——save()、updateAll() 都不会。
- MySQL 层配置建议：把
innodb_lock_wait_timeout调为5~10秒，缩短等待窗口 - PHP 层必须手动加重试：最多 3 次，每次间隔
usleep(50000)（50ms），错开竞争时间点 - 重试超过 3 次会把雪崩变成持续抖动，不解决根因反而放大问题
多表更新必须统一加锁顺序
两个事务一个按 product → order 加锁，另一个按 order → product，只要并发一上来，死锁几乎必现——这不是概率问题，是设计缺陷。
- 所有涉及多表变更的业务（如扣库存+写订单+减余额），必须约定全局顺序，例如固定为：
Product → Order → UserAccount - 在代码里用注释或常量明确标出：
// LOCK ORDER: Product → Order → Wallet，比文档更可靠 - 若需反向逻辑（如退款），拆成两个独立事务，中间不跨锁，用最终一致性兜底
乐观锁仅防写冲突，不解决读-改-写竞态
version 字段能拦住“两人同时改同一行”，但拦不住“查库存→判断够不够→扣减”这种三步操作中的并发覆盖。
- 乐观锁需配合
WHERE version = ?条件更新，且更新后检查影响行数是否为 1 - 对强一致性要求高的场景（如库存扣减），悲观锁 + 统一顺序仍是更稳妥选择
- 别把乐观锁当银弹，它解决的是“最后写胜出”，不是“过程不冲突”
