laravel并发库存扣减应优先用db::update()原子sql，如db::update('update products set stock = stock - 1 where id = ? and stock >= ?', [$id, $quantity])，失败时db::affectingstatement()返回0；避免model->save()导致的“查+改”分离与超卖。
用 DB::update() 做带条件的原子扣减，别碰 Model->save()
库存超卖最常见原因就是“查+改”两步分离：先 Product::find($id) 读出 stock = 1，再 $product->decrement('stock')，最后 $product->save()。两个请求几乎同时执行，都会走通这个流程，结果 stock 变成 -1。
根本解法是把“检查是否够卖”和“扣减”压进一条 SQL 里，由数据库保证原子性：
- 写法必须是
DB::update('UPDATE products SET stock = stock - 1 WHERE id = ? AND stock >= ?', [$id, $quantity]) - 返回值直接判断：
if (DB::affectingStatement() === 0) { // 库存不足 } - 千万别在事务里先
select再update，除非你明确需要SELECT FOR UPDATE - 这条语句不触发 Eloquent 的事件、访问器、类型转换，副作用最小
高并发下要加锁？优先用 SELECT FOR UPDATE，但得写对
当业务逻辑不能单条 SQL 完成（比如要校验用户等级、调外部风控接口、生成唯一单号），就必须先读再改——这时得加行级锁，且必须从事务一开始加。
错误写法：Product::lockForUpdate()->find($id)，它可能触发懒加载或额外查询，延长锁持有时间，增加死锁概率。
正确姿势：
- 手动开启事务：
DB::beginTransaction() - 立刻执行原生查询：
DB::select('SELECT * FROM products WHERE id = ? FOR UPDATE', [$id]) - WHERE 条件必须命中主键或唯一索引，否则会升级为表锁
- 锁等待超时由 MySQL 的
innodb_lock_wait_timeout控制（默认 50 秒），不是 PDO 的ATTR_TIMEOUT
Redis 做库存计数时，只用原子命令，别用两次操作
用 Redis 管理库存，核心就一条：所有判断 + 修改必须在一个原子操作内完成。任何“先 llen 再 lpush”或“先 get 再 set”都是漏洞。
可靠方案只有两个：
-
INCRBY：初始化SETNX goods:stock:1 0，每次抢购执行INCRBY goods:stock:1 1，判断返回值是否 ≤ 总库存 -
LPOP或RPOP：预填充LPUSH goods:queue:1 1 1 1 ...（N 个占位符），抢购时LPOP goods:queue:1，返回非空即成功 - 别用
GET + SET组合，也别依赖客户端做 if 判断——网络延迟和执行间隙就是超卖温床
事务自动重试能缓解死锁，但不能替代锁设计
Laravel 的 DB::transaction() 默认会重试 5 次死锁异常，这能掩盖一部分问题，但绝不意味着你可以随便写锁逻辑。
真正容易被忽略的是锁粒度和顺序：
- 多个商品同时扣减时，必须固定加锁顺序（比如按 ID 升序），否则极易死锁
- 事务里不要做耗时操作（如 HTTP 请求、文件读写），锁持有时间越长，冲突概率越高
- 如果用了 Redis 锁（如
RedLock），注意它和数据库锁不是一回事——Redis 锁只保“互斥”，不保“事务一致性”
