thinkphp 的 lock(true) 本质不是自动的 select ... for update，必须在 innodb 事务中配合 where() 和 find() 使用才生效，否则无行锁效果。
ThinkPHP 的 lock(true) 本质是 SELECT ... FOR UPDATE 吗？
不是自动的。ThinkPHP 的 lock(true) 默认只加表级锁（MyISAM）或无实际行锁效果（InnoDB 下不带事务时），它本身不触发 SELECT ... FOR UPDATE。真正起作用的前提是：必须在数据库事务中调用，且底层驱动支持行锁（如 MySQL + InnoDB）。
常见错误现象：lock(true) 单独调用后库存仍被并发扣减——因为没进事务，查询结果没被锁定，后续 save() 是普通更新。
- 必须配合
Db::transaction()或模型的startTrans()使用 - MySQL 表引擎必须为 InnoDB（MyISAM 不支持行级锁）
- 查询语句需命中索引，否则可能升级为表锁（如 WHERE 条件无索引）
正确写法：事务内先查再锁再更新
核心逻辑不是“锁住再查”，而是“查的时候就带上锁”，即用带 FOR UPDATE 的 SELECT 触发行锁。ThinkPHP 中需手动拼写或借助 lock() 配合事务。
推荐实操写法（以商品库存扣减为例）：
Db::transaction(function () use ($goodsId, $num) {
// 这行会生成 SELECT * FROM `goods` WHERE `id` = ? FOR UPDATE
$goods = Db::name('goods')->where('id', $goodsId)->lock(true)->find();
<pre class="brush:php;toolbar:false;">if (!$goods || $goods['stock'] where('id', $goodsId)->update([
'stock' => $goods['stock'] - $num
]);});
注意：lock(true) 必须紧跟在 where() 后、find() 前；放在 update() 前无效。
- 不能写成
->lock(true)->update(...)—— update 不走 select，锁不住 - 若用模型操作，确保模型对应表是 InnoDB，且主键有索引
- 事务超时时间需检查配置
db.deploy.timeout，避免长事务阻塞
为什么不用 lock(false) 或字符串锁？
lock(false) 是表锁（LOCK TABLES ... WRITE），并发性能极差，会直接卡住其他读写；传字符串如 lock('update') 在 ThinkPHP 6+ 已废弃，且行为不可控。
真实场景下，只要涉及单行/少量行的并发修改（如订单扣库存、抢红包余额），就必须用行级悲观锁 + 事务。表锁只适用于全表维护类操作，比如凌晨跑数据修复。
- 高并发下单时，
lock(false)会让所有请求排队等同一张表，QPS 断崖下跌 - 部分旧文档写的
lock('x')在 TP6.1+ 不生效，底层已移除该逻辑 - 如果业务需要锁多行（如批量扣多个商品），WHERE 条件必须能命中索引，否则容易锁表
容易被忽略的三个细节
很多线上超卖不是因为不会写锁，而是栽在这几个边界上：
- 事务未捕获异常导致连接未释放——务必用
try/catch包裹或依赖闭包自动回滚 - 查询条件用了函数或隐式转换（如
where('id', strval($id))），导致索引失效，锁升级为表锁 - Redis 缓存与 DB 锁不同步：缓存里显示有货，DB 里已被锁住但还没更新，此时应让缓存降级或加本地锁兜底
悲观锁不是银弹，它把并发压力从“数据不一致”转成了“响应延迟”。真要扛万级 QPS，得结合库存预占、分段锁或最终一致性方案。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
