Yii框架不提供RESTful接口级悲观锁抽象，必须手动开启事务并用createCommand执行SELECT...FOR UPDATE，后续操作需在同一事务内完成，AR的save()等方法不会自动加锁。
Yii 框架本身不提供 RESTful 接口级的“悲观锁”抽象，SELECT ... FOR UPDATE 必须手动在事务中显式调用，且仅在 InnoDB + 手动事务控制下生效。直接依赖 ActiveRecord 的 save() 或 updateAll() 不会自动加行锁。
RESTful 接口中怎么触发 MySQL 行级悲观锁
悲观锁不是 Yii 的功能开关，而是你主动发起的数据库语句行为。关键点在于：必须开启事务、使用原生 SQL 或 createCommand() 执行 SELECT ... FOR UPDATE，且不能依赖 AR 查询结果直接修改后 save() —— 那样会丢失锁上下文。
- 必须用
Yii::$app->db->beginTransaction()显式开启事务（InnoDB 默认 autocommit=1，不开启事务时FOR UPDATE无效） - 锁必须由
createCommand()发起，例如：Yii::$app->db->createCommand("SELECT * FROM user WHERE id = :id FOR UPDATE")->bindValue(':id', $id)->queryOne() - 后续的
UPDATE或业务逻辑必须在同一事务内完成，否则锁在查询后立即释放 - AR 的
findOne()返回对象后调用$model->save()，底层走的是普通 UPDATE，不会复用之前查到的锁 —— 这是常见误解
为什么 ActiveRecord::update() 不带悲观锁
因为 ActiveRecord::update() 和 updateAll() 底层只拼 WHERE 条件执行 UPDATE，不感知事务锁状态，也不执行 SELECT 阶段。它没有“先查再锁再改”的语义，只是原子性写操作。即使你在事务里调用 $model->save()，也只保证写入的原子性，不保证读取时的数据独占性。
- 想在更新前确保数据未被他人修改，必须自己先
SELECT ... FOR UPDATE查一次并保持事务打开 -
$model->refresh()会重新查库，但不加锁，无法替代FOR UPDATE - 若强行在 AR 中封装
FOR UPDATE，需重写find()方法并绑定事务，但违背 Yii 的设计习惯，易出错
实际 RESTful 场景中的典型写法（以订单扣库存为例）
假设接口是 PUT /api/items/123/lock，目标是锁定商品并预留库存。不能靠 AR 自动处理，得手写事务块：
$transaction = Yii::$app->db->beginTransaction();
try {
// 关键：原生查询 + FOR UPDATE
$row = Yii::$app->db->createCommand(
'SELECT id, stock, version FROM item WHERE id = :id FOR UPDATE'
)->bindValue(':id', $itemId)->queryOne();
<pre class="brush:php;toolbar:false;">if (!$row || $row['stock'] < 1) {
throw new BadRequestHttpException('库存不足');
}
// 执行业务逻辑（如生成预订单、扣减库存）
Yii::$app->db->createCommand()->update('item', [
'stock' => $row['stock'] - 1,
'version' => $row['version'] + 1,
], ['id' => $itemId])->execute();
$transaction->commit();
return ['status' => 'locked', 'stock' => $row['stock'] - 1];} catch (\Exception $e) { $transaction->rollBack(); throw $e; }
- 整个过程必须在单个事务内完成，不能拆成多个 HTTP 请求或多个
createCommand()独立调用 - 如果接口是无状态的 RESTful，注意事务生命周期不能跨请求；锁只在当前请求内有效
- 高并发下
FOR UPDATE可能导致请求排队等待，需监控锁等待时间（innodb_row_lock_time_avg）
真正难的不是写那句 FOR UPDATE，而是判断哪里该加、加多久、失败后怎么降级——比如超时自动放弃，或 fallback 到乐观锁重试。这些决策不在框架里，而在你的业务边界里。
