ThinkPHP乐观锁实现方法与版本号更新技巧详解

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在ThinkPHP框架中实现有效的乐观锁机制，开发者必须明确一个核心前提：框架本身并未内置开箱即用的乐观锁功能。真正的乐观锁实现，完全依赖于开发者手动构建一条包含版本校验的原子性UPDATE语句。如果未能遵循此原则，所谓的锁机制将形同虚设。

为何 save() 结合 where('version', $old) 是唯一可靠方案

许多开发者存在一个常见误解，认为使用模型的 save() 方法即可自动处理版本冲突。实际上，ThinkPHP 6的 save() 方法本质是将传入的数组数据组装为SQL的SET子句，它不会自动校验该记录在读取后是否已被其他操作修改。

举例说明：首先通过 find() 查询到一条记录，其 version 字段值为5。随后调用 save(['version' => 6, 'stock' => 99]) 尝试更新。若此次更新未在WHERE条件中显式指定 version = 5，则乐观锁逻辑将被完全绕过。在 save() 执行前，其他并发请求可能已将版本号更新至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() 加 save() 的分步操作，则锁仅在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()->save() 模式来封装乐观锁逻辑，即便将其包装在模型方法内部。只要底层执行被拆分为先SELECT后UPDATE两步，便无法保证操作的原子性，自然也就不是真正的乐观锁实现。