ThinkPHP 6 的 save() 不会自动更新 _version 字段，必须手动在查询时读取当前值、更新时用 where(['id'=>$id,'_version'=>$oldVersion]) 校验，并成功后主动赋值 $model->_version = $oldVersion + 1，且必须检查 save() 返回值是否为 true。
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，可此时你并不知道是失败了，因为没检查返回值。
立即学习“PHP免费学习笔记（深入）”；
- 必须显式判断
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 加索引，就容易引发锁竞争。
- 务必确保乐观锁的 WHERE 条件中至少有一个等值查询字段是索引列（最好是主键或唯一索引）
- 不要指望
_version字段自己建索引就能解决问题——它只是辅助校验，不是查询入口 - 如果业务允许，可在关键路径上加
SELECT ... FOR UPDATE做强一致性保护，但这和乐观锁是两种思路，混用容易翻车
_version，而不是复用上次查询结果；还有就是没检查 save() 返回值，让锁形同虚设。 
