sharedlock() 仅用于“读校验不修改”的并发安全场景，如验证用户活动资格、优惠券状态或余额充足性；它允许多事务并发读但阻塞写操作，不可用于库存扣减等读-改-写流程，否则会导致超卖。
sharedLock() 不是用来防写覆盖的，它只阻塞其他事务的写操作，不阻止读——别指望靠它解决库存超卖。
sharedLock() 适合什么场景
它本质是 SQL 的 SELECT ... LOCK IN SHARE MODE，适用于「需要校验但不修改」且允许并发读的逻辑。比如下单前检查用户是否已参与活动、验证优惠券是否未被使用、确认账户余额是否充足等。
常见错误是把它当 lockForUpdate() 用：两个请求同时 sharedLock() 读到库存为 5，都判断“够用”，然后各自扣减——结果变成 3 而不是预期的 4。
- 必须包裹在
DB::transaction()中，否则锁在查询后立即释放 - 仅对 InnoDB 有效，SQLite 不支持
- 多个事务可同时持有同一行的 sharedLock，但任一事务尝试
lockForUpdate或普通UPDATE会被阻塞，直到所有 sharedLock 释放
怎么正确调用 sharedLock()
不能在模型实例上链式加锁，比如 Product::find(1)->sharedLock() 是无效的——find() 已执行完查询，锁根本没加上。
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
必须从查询构造器开始构建，且锁定动作要出现在 get() 或 first() 之前：
DB::transaction(function () {
$product = DB::table('products')
->where('id', 1)
->sharedLock()
->first();
if ($product && $product->stock > 0) {
// 仅校验，不更新
return true;
}
});
- 不支持 Eloquent 模型的静态
find()、first()直接加锁；要用where()->sharedLock()->first() - 如果后续要更新，应直接换用
lockForUpdate()，sharedLock + update 组合需额外手动处理锁升级，不可靠 - 注意 MySQL 隔离级别：在
READ COMMITTED下，sharedLock 只锁住命中的行；在REPEATABLE READ下可能触发间隙锁（gap lock）
sharedLock 和 lockForUpdate 的关键区别
sharedLock 允许多个事务同时读同一行，但会阻止任何事务对该行执行 UPDATE、DELETE 或再次加 lockForUpdate；而 lockForUpdate 会阻止其他事务对该行做任何读（指加锁读）和写操作。
典型误判是认为 “sharedLock 后别人就读不到这行了”——其实普通 SELECT 依然能读，只是不能改。这也是为什么它不适合扣库存这类“读-改-写”流程。
- sharedLock → 适合只读校验，高并发下吞吐量更高
- lockForUpdate → 适合读取后必更新的场景，如减库存、改订单状态
- 两者都不解决主从延迟导致的读到旧值问题；若业务强依赖主库实时数据，需强制走主库连接
sharedLock 的价值不在“锁得多严”，而在“锁得恰如其分”：它用最小代价防止写冲突，但绝不该被当作并发写的安全兜底。真正要保数据不丢不重，得看清楚你是在读，还是在读完就要改——后者绕不开 lockForUpdate 和事务包裹。
