Hyperf 中 selectForUpdate 易失效，因协程池连接复用、未显式事务、无索引导致锁升级、事务内混入耗时操作；正确做法是手动获取 PDO、显式事务、同一连接执行查询与更新。
Hyperf 本身不封装 SELECT ... FOR UPDATE 的语义，它依赖底层 PDO 和事务管理机制；你得自己控制事务边界、显式加锁、并确保连接不被协程误复用——否则看似加了锁，实际锁不住。
为什么直接在 Hyperf 里用 selectForUpdate 容易失效
Hyperf 的数据库操作默认走协程池，selectForUpdate 必须在同一个数据库连接、同一事务内完成“查询 + 后续 update”，但以下情况会让锁形同虚设：
- 没手动开启事务（
beginTransaction()），PDO 自动 commit 后锁立刻释放 - 用了 Swoole 协程池，但没禁用连接复用：A 协程查完锁住某行，连接被池子回收后分配给 B 协程，B 却在无事务上下文中执行 update —— 锁早没了
- WHERE 条件没命中索引，InnoDB 退化为表锁或间隙锁，锁范围远超预期
- 事务中混入了 HTTP 调用、日志写入、
sleep()等耗时操作，导致锁持有时间过长，排队雪崩
selectForUpdate 在 Hyperf 中的正确写法
必须满足三个硬性条件：显式事务 + 连接绑定 + 索引保障。示例代码不是“调个方法就行”，而是结构约束：
// ✅ 正确模式：手动事务 + 强制使用同一连接
$connection = $this->db->getPdo(); // 拿原生 PDO，避免框架自动 commit
$connection->beginTransaction();
<p>try {
// 1. 显式 select for update，必须命中索引
$stmt = $connection->prepare('SELECT stock FROM goods WHERE id = ? FOR UPDATE');
$stmt->execute([123]);
$stock = $stmt->fetchColumn();</p><pre class="brush:php;toolbar:false;">if ($stock > 0) {
// 2. 同一连接执行 update
$connection->prepare('UPDATE goods SET stock = stock - 1 WHERE id = ?')->execute([123]);
}
$connection->commit();} catch (\Throwable $e) { $connection->rollback(); throw $e; }
关键点：
- 不要用
$db->select()->forUpdate()这类 QueryBuilder 封装——Hyperf 的 QueryBuilder 不保证事务内复用连接 - 必须用
getPdo()拿底层连接，并全程自己管理beginTransaction/commit/rollback -
FOR UPDATE后面别加ORDER BY或LIMIT（除非确认索引覆盖且执行计划稳定），否则可能触发额外间隙锁
比 selectForUpdate 更稳的替代方案
悲观锁在高并发下本质是“排队等”，而 Hyperf 的协程模型让等待线程不阻塞 CPU，但锁等待本身仍拖慢吞吐。更推荐组合策略：
-
前置缓存校验：先查 Redis 缓存库存（
GET goods:123:stock），为 0 就直接返回，不进 DB -
分段更新（shard by slot）：把单行库存拆成 10 行，
UPDATE goods_stock SET stock = stock - 1 WHERE product_id = 123 AND shard_id = ?，随机选槽，锁竞争下降 80%+ - 最终一致性扣减：扣减写入消息队列（如 Kafka），DB 异步消费更新，接口只返回“已受理”，不强求实时扣成功
注意：selectForUpdate 不是银弹。它适合低频、强一致、已知热点行的场景（如订单支付锁单）；秒杀、抢购这类流量洪峰，优先靠分段+缓存+队列把压力从 DB 层卸掉。
真正容易被忽略的是：Hyperf 的协程上下文不会自动传递事务状态。你在主协程开了事务，起一个子协程去执行 selectForUpdate，那个子协程拿到的极大概率是另一个连接——锁根本不在同一行上。
