ThinkPHP乐观锁怎么实现_ThinkPHP版本号更新技巧【汇总】

在ThinkPHP框架里实现真正的乐观锁，有个核心事实必须明确：框架本身并没有提供开箱即用的乐观锁功能。所谓的“乐观锁”，完全依赖于开发者手动构造一条带有版本校验的原子UPDATE语句。如果没做到这一点，那所谓的锁就只是个摆设。

为什么 sa ve() + where('version', $old) 是唯一靠谱路径

很多开发者容易掉进一个误区，以为用模型的 sa ve() 方法就能自动处理版本冲突。其实不然。TP6的 sa ve() 方法本质上只是将你传入的数组数据拼装成SQL的SET子句，它不会自动校验这条记录在你读取之后是否被他人修改过。

举个例子，你先通过 find() 查到一条记录，其 version=5。接着你调用 sa ve(['version' => 6, 'stock' => 99]) 试图更新。如果这次更新没有在WHERE条件里显式指定 version = 5，那么这次操作将完全绕过乐观锁的逻辑。在你执行 sa ve() 之前，其他请求可能已经把版本号更新到了6甚至7，你的这次更新就会直接覆盖掉别人的修改，导致数据错乱。

所以，乐观锁的灵魂在于WHERE条件中的版本比对，而不是更新操作本身。正确的姿势必须是显式地构建查询：

$res = Db::name('goods')
    ->where('id', 123)
    ->where('version', $expectedVersion)
    ->update([
        'stock' => Db::raw('stock - 1'),
        'version' => Db::raw('version + 1'),
        'updated_at' => time()
    ]);

执行后，根据返回值就能清晰判断结果：

• $res === 1：更新成功，数据被安全扣减，版本号也已递增。
• $res === 0：更新失败，WHERE条件不匹配（说明别人已经抢先修改了数据）。这时你需要决定是重试还是向用户返回冲突错误。
• $res === false：SQL语句执行失败，可能是字段不存在、权限不足等异常情况。

别信 lock(true) 在乐观锁场景下的作用

这里有个常见的混淆点。lock(true) 是ThinkPHP提供的悲观锁接口，其底层会生成 SELECT ... FOR UPDATE 语句。它和基于版本号的乐观锁是两套完全不同的并发控制机制，不仅不互补，甚至可能互相干扰。

如果你在事务中混合使用 lock(true) 和版本号更新，不仅无法获得叠加的“双保险”效果，反而容易引发死锁，或者掩盖真正的并发问题。比如，你用 lock(true) 锁住一行记录进行查询，但后续的更新操作如果还是拆分成 find()+sa ve() 两步，那么锁只在SELECT那一刻有效，随后的UPDATE仍然可能因为版本号不匹配而失败，或者错误地覆盖数据。

更危险的是，有些开发者误以为加了 lock(true) 就等于启用了乐观锁，于是代码里完全省略了版本号的校验逻辑。这种误解一旦上线，在高并发场景下（比如秒杀）极易导致库存超卖等严重问题。

事务里用乐观锁，startTrans() 只是锦上添花

需要理解，乐观锁的核心能力来源于单条UPDATE语句的原子性。即使不开启数据库事务，这条带版本校验的UPDATE语句本身也能正常工作。

那么，什么时候需要搭配事务（Db::startTrans()）呢？通常是在业务逻辑涉及多表操作时。例如，在扣减商品库存的同时，还需要创建订单记录、写入操作日志。这时开启事务，是为了保证这一系列操作要么全部成功，要么全部回滚，保持数据的一致性。

但是，必须警惕一个关键点：事务并不会增强乐观锁的版本校验能力。如果你在一个事务内，需要基于同一个查询结果更新多个记录，必须为每一条更新都重新获取最新的版本号。常见疏漏包括：

• 在事务中多次复用同一个旧的 $expectedVersion 变量。
• 在第二次更新前，没有重新查询数据库获取最新的 version 值，而是直接使用了缓存或Session中的旧值。
• 没有检查 update() 方法的返回值，错误地将返回0（代表版本冲突，未更新任何行）当作成功处理。

版本字段选 version 还是 updated_at？

从可靠性出发，强烈建议使用独立的 version 字段。原因在于，updated_at 时间戳在高并发下存在重复的风险。MySQL的timestamp类型默认精度只到秒，而PHP的 time() 函数在极短时间间隔内也可能返回相同的值。如果两个并发请求都读到了相同的 updated_at 时间，那么它们构造的WHERE条件会一模一样，最终只有一个请求的UPDATE能成功，另一个则会静默失败。这并非我们期望的“发现并处理冲突”，而是变成了“随机丢弃请求”。

使用整型的 version 字段则没有这个问题。每次更新必然递增，语义清晰，且无精度困扰。另外，别忘了给这个字段加上索引，否则 WHERE version = ? 这样的条件查询可能会引发全表扫描，影响性能。

最后再次强调，不要试图用 find()->sa ve() 这种模式来封装乐观锁逻辑，哪怕你把它包装在模型的方法内部。只要底层执行被拆分成先SELECT后UPDATE两步，它就无法保证操作的原子性，自然也就不是真正的乐观锁。