悲观锁selectForUpdate()在事务中会阻塞，但仅限数据库行级锁，需DB::transaction()包裹且where条件命中索引；乐观锁靠version校验实现无锁并发控制；sharedLock()允许多读但阻塞写，不防丢失更新。
悲观锁：selectForUpdate() 在事务中真的会阻塞吗
会，但仅限于数据库层面的行级锁，且必须在事务内生效。脱离 DB::transaction() 或未开启自动提交关闭（PDO::ATTR_AUTOCOMMIT => false）时，selectForUpdate() 可能静默失效或退化为普通查询。
常见错误现象：SQLSTATE[HY000]: General error: 1205 Deadlock found when trying to get lock —— 多个请求同时对同一组记录加锁且顺序不一致，触发 MySQL 死锁。
- 务必用
DB::transaction()包裹整个读-改-写流程，不能只给selectForUpdate()加事务 - 锁的范围由 where 条件决定：无索引字段会导致表锁，有复合索引但未覆盖查询条件也会升格为间隙锁
- MySQL 中 InnoDB 的
SELECT ... FOR UPDATE在可重复读（RR）隔离级别下默认加临键锁（Next-Key Lock），可能锁住不存在但“应该存在”的间隙 - 示例：
DB::transaction(function () { $user = User::where('id', 123)->lockForUpdate()->first(); $user->balance -= 100; $user->save(); });
乐观锁：用 increment() 和 where version=xxx 避免覆盖写
乐观锁本质是“先查后验”，不依赖数据库锁机制，靠业务字段（如 version 或 updated_at）做并发校验。Laravel 自带的 increment()、decrement() 是原子操作，但不自带版本检查；需手动拼 where 条件。
容易踩的坑：$model->version++ + $model->save() 不是原子的，两个请求可能读到相同 version，都写入 version=2，丢失一次更新。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法是用
whereRaw('version = ?', [$oldVersion])做更新前置校验，再用update()一次性完成 - 若返回影响行数为 0，说明已被其他请求抢先更新，应重试或抛异常
-
increment()本身安全，但仅适用于纯数值累加场景（如计数器），无法替代带业务逻辑的“读-改-写” - 示例：
$affected = User::where('id', 123) ->where('version', $expectedVersion) ->update(['balance' => DB::raw('balance - 100'), 'version' => DB::raw('version + 1')]);
selectForUpdate() 和 sharedLock() 的实际区别在哪
selectForUpdate() 加排他锁（X Lock），阻止其他事务读写该行；sharedLock() 加共享锁（S Lock），允许其他事务加 S 锁（即并发读），但会阻塞 X 锁（写操作）。两者都只在事务中有效，且都要求 where 条件命中索引。
典型误用：sharedLock() 被当成“读不阻塞”的万能方案——但它并不能防止 A 读、B 写、A 再写导致的覆盖问题（即丢失更新），它只防“写-写冲突”，不防“读-写-写”。
- 想防止别人修改当前行 → 用
selectForUpdate() - 只想防止别人修改，但允许多人同时读（比如生成报表前确认数据未被编辑）→ 用
sharedLock() - 二者都不解决幻读；如需锁定范围（如“所有 status=0 的订单”），必须配合
WHERE精确命中索引，否则可能锁表 - MySQL 中
sharedLock()对应SELECT ... LOCK IN SHARE MODE，注意某些存储引擎（如 MyISAM）不支持
高并发下 update() 带 where 条件为什么有时像乐观锁
因为 InnoDB 的 UPDATE 语句在执行时会先定位记录并加 X 锁，再判断 WHERE 条件是否满足；若不满足，锁会立刻释放。所以多个请求同时执行 User::where('balance', '>=', 100)->decrement('balance', 100)，最终只有第一个成功扣减，其余因条件不满足而跳过——这看起来像乐观锁行为，但底层仍是悲观锁机制。
关键点在于：这不是“无锁重试”，而是“锁了再判，不满足就放”。如果业务需要明确知道是否被抢，不能只靠 affected rows 为 0 就认为失败，得结合具体逻辑判断（比如余额是否真不足）。
- 这种模式适合幂等性要求高、失败可接受的场景（如优惠券核销）
- 不适合需要严格顺序或必须成功一次的场景（如库存预占），此时仍需显式加锁或队列削峰
- 注意
decrement()不会触发模型事件（saving/saved），如有审计日志等需求，得手动补全
实际用哪一种，取决于你能否容忍“重试”、数据库是否支持行锁、以及业务对一致性的容忍边界。悲观锁容易死锁，乐观锁容易重试失败，而看似简单的 update() + where 其实暗藏锁生命周期细节——这些地方，线上出问题时往往最先崩。
