thinkphp 6 中乐观锁需通过原子化 update 实现，依赖数据库行级锁与影响行数判断成败，不可用 find+save 模拟；推荐使用 whereraw+db::raw 构造带条件更新，并检查 affectedrows。
ThinkPHP 6 的 where + setInc / setDec 不能直接实现乐观锁
乐观锁在 ThinkPHP 中不是开箱即用的功能，它依赖你主动在 SQL 层面控制版本字段或条件表达式。TP6 的 where 查询链式调用本身不带原子性校验，比如你先 select 库存再 update，中间就可能被其他请求改掉——这根本不是乐观锁，是“幻读式伪锁”。
真正能落地的路径只有一条：把「读取当前值 + 判断是否足够 + 扣减」三步压缩进一条 UPDATE 语句里，靠数据库的行级锁和返回影响行数来判断成败。
- 别用
find()后手动计算再save()，这是并发漏洞高发区 - TP6 的
update()方法支持传入闭包条件，但必须配合affectedRows()检查结果，否则无法知道扣减是否成功 - MySQL 的
WHERE stock >= 1是安全底线，但仅靠它还不够——得确保这个条件基于你「刚读到的版本」或「当前最新值」
用 Db::raw() 写原生 UPDATE 实现库存扣减原子判断
ThinkPHP 的查询构造器对复杂条件更新支持有限，尤其涉及「比较自身字段值」时（如 stock > 0），用 where('stock', '>=', $current) 本质还是拼参数，无法防止并发覆盖。最稳的方式是绕过 ORM，用 Db::raw() 构造带条件的 UPDATE，并检查执行后是否真有行被修改。
示例场景：用户下单扣减商品 ID=123 的库存，要求至少剩 1 件才允许扣 1 件：
$res = Db::name('goods')->where('id', 123)
->update([
'stock' => Db::raw('stock - 1'),
'updated_at' => time()
]);
if ($res === false) {
throw new Exception('数据库更新失败');
}
if ($res === 0) {
throw new Exception('库存不足或已被抢完');
}
-
$res是 int 类型，等于 1 表示成功扣减，0 表示 WHERE 条件不满足（比如 stock 已为 0） - 这里没显式写
WHERE stock >= 1，是因为stock - 1在 stock=0 时会变成 -1，但更重要的是：只要 stock 字段当前值不满足扣减前提，整行就不会被更新 - 如果你还用了版本号字段（如
version），就得写成WHERE id = 123 AND version = {$expectedVersion}，并在 update 里同步version = version + 1
TP6 模型中封装乐观扣减方法时，save() 的 where 参数容易漏掉并发约束
有人会在模型里写一个 decreaseStock($id, $num) 方法，然后用 $model->where(...)->save(['stock' => $newStock])。问题在于：这个 where 如果只写主键，就完全没做业务校验；如果写了 stock >= $num，又容易把变量直接拼进去，导致 SQL 注入或类型隐式转换出错。
- 永远不要把用户输入或计算结果直接塞进
where数组的 value 位，比如['stock', '>=', $request->post('num')]—— 这里 $num 可能是字符串或负数，触发非预期行为 - 正确做法是用
whereRaw()显式控制 SQL 片段：whereRaw('stock >= ?', [$num])，既防注入，又保类型 - 注意
save()返回布尔值，不是影响行数，所以必须搭配Db::getPDO()->lastInsertId()或更推荐的Db::raw('ROW_COUNT()')来确认是否真改了数据
Redis + MySQL 双写场景下，INCRBY 和数据库 UPDATE 的顺序与回滚难兼顾
有些项目用 Redis 缓存库存做快速预减（DECRBY），再异步落库。这看似提升性能，实则把一致性难题从“单库并发”升级成“跨系统状态同步”。一旦 Redis 扣成功但 MySQL 失败，库存就永久少一笔。
- 除非你实现了可靠的本地消息表 + 定时补偿，否则别在核心扣减路径上引入 Redis 预减
- 如果坚持要用，务必让 Redis 操作成为「可逆」步骤：先
GET当前值，再DECRBY，拿到新值后立刻用 Lua 脚本原子判断是否 ≥0；失败则用INCRBY回滚 - MySQL 端的 UPDATE 必须带上和 Redis 一致的初始值校验，比如 Redis 记录的是 version=5，那 DB 更新也得
WHERE version = 5，否则双写不同步
真正的难点从来不在怎么写那条 UPDATE，而在于你是否清楚每一次 where 条件背后，数据库到底锁了哪几行、是否允许幻读、事务隔离级别有没有拖后腿。这些细节不抠清楚，加再多层“锁”也只是自我安慰。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
