如何在ThinkPHP中实现乐观锁并发控制_version版本号字段自动递增机制-ThinkPHP-PHP中文网

thinkphp 6 的 save() 不会自动更新 _version 字段，必须手动在查询时读取当前值、更新时用 where(['id'=>$id,'_version'=>$oldversion]) 校验，并成功后主动赋值 $model->_version = $oldversion + 1，且必须检查 save() 返回值是否为 true。

如何在thinkphp中实现乐观锁并发控制_version版本号字段自动递增机制

ThinkPHP 6 的 `save()` 如何自动更新 `_version` 字段

ThinkPHP 本身不内置乐观锁字段的自动递增逻辑，_version 字段不会像数据库自增主键那样被框架自动识别和处理。必须手动干预更新条件与赋值时机。

常见错误现象是：写了一个 _version 字段，也加了 where 条件，但并发时仍出现覆盖写入——根本原因是没在 save() 前把当前版本号读出来并塞进 where，或者没在成功更新后主动把新版本号回写到模型实例中。

使用场景：订单状态变更、库存扣减、用户资料编辑等需防止“写覆盖”的业务
正确做法是在查询时带上 _version，更新时用 where(['id' => $id, '_version' => $oldVersion])，且成功后立即执行 $model->_version = $oldVersion + 1
别依赖 updateTime 或事件钩子自动加 1；TP6 的 afterUpdate 钩子触发时 SQL 已执行完毕，此时再改 _version 没意义

为什么不能只靠 `where` + `inc('_version')`？

直接在 save() 里写 ['_version' => ['inc', 1]] 看似简洁，但会破坏乐观锁语义：它会让 WHERE 条件里的 _version 和 SET 里的 _version 不同步，导致条件失效。

例如你查出 _version = 5，然后执行 save(['_version' => ['inc', 1]], ['id' => 1, '_version' => 5])，TP 底层拼 SQL 时可能把 inc 转成 SET _version = _version + 1，而 WHERE 仍是 _version = 5 —— 这没问题；但一旦有其他并发请求抢先更新了这条记录，你的 WHERE 就不成立，save() 返回 false，可此时你并不知道是失败了，因为没检查返回值。

必须显式判断 save() 返回值是否为 true，否则等于没加锁
inc 在 save() 中不推荐用于乐观锁字段，易混淆读-改-写流程
更安全的做法是：先 select 拿到当前 _version，再构造精确 where，最后用普通赋值方式写新值（如 ['_version' => $oldVersion + 1]）

TP6 模型事件中如何安全嵌入版本校验逻辑

想把版本校验收口到模型层，可以用 beforeWrite 和 afterWrite 事件，但要注意触发顺序和数据可见性。

关键点在于：beforeWrite 只能拿到即将写入的数据，拿不到数据库当前值；所以它不适合做“对比校验”，只适合做“预设新值”。真正的校验必须放在 save() 执行前的手动 where 构造里。

beforeWrite 可用于自动补全 _version 字段（比如从传入数据里取旧值+1），但前提是旧值已存在上下文中
真正防并发的校验动作必须发生在 DAO 层：即调用 save() 前，自己拼好带 _version 的 where
不要在 afterWrite 里尝试重试或抛异常——此时写操作已完成，失败已成事实

MySQL 行级锁配合 `_version` 是否多余？

在高并发扣库存等场景下，单靠 _version + UPDATE WHERE 可能不够稳。因为 MySQL 的 UPDATE WHERE 在无索引字段或锁粒度粗时，可能升级为表锁或间隙锁，反而拖慢整体吞吐。

所以要确认 _version 所在的 WHERE 条件是否命中索引。例如 WHERE id = ? AND _version = ?，只要 id 是主键，MySQL 就只会锁这一行；但如果写成 WHERE status = 'pending' AND _version = ?，又没给 status 加索引，就容易引发锁竞争。