laravel 11 中数据库缓存锁由 redis 缓存锁（cache::lock）和数据库行锁（select for update）组成，二者定位不同、不可替代，需协同使用；必须配置 redis 驱动、正确命名锁键、合理设置 ttl，并在锁闭包内结合数据库事务与行锁保障最终一致性。
在 Laravel 11 中，数据库缓存锁不是单一功能，而是由两套独立但常协同使用的机制组成：一是基于 Redis 的 缓存锁（Cache::lock），用于分布式临界区控制；二是数据库层的 事务隔离 + 行锁语句（如 SELECT FOR UPDATE），用于保障写操作原子性。二者定位不同，不能互相替代，但搭配得当可有效防止超卖、重复处理、数据覆盖等并发问题。
必须用 Redis 驱动才能真正生效
Cache::lock() 在 database 或 file 驱动下无法保证原子性，高并发时大概率失效。生产环境必须满足：
- CACHE_DRIVER=redis 已配置在 .env 中
- config/cache.php 中 redis store 的 connection 名与 config/database.php 的 redis 配置一致
- 若使用 Laravel Octane，Redis 连接需启用 persistent 模式，否则锁状态无法跨请求保持
- 执行 php artisan tinker --execute="dd(Cache::lock('test', 1)->get())" 返回 true 才算通路正常
正确调用 lock()：区分 get() 和 block()
→get() 是非阻塞模式：立即尝试加锁，成功则执行闭包，失败直接跳过，不等待；适合幂等性强、允许“本次跳过”的场景，例如生成临时 token 或刷新统计计数。
→block(5) 是阻塞模式：最多等待 5 秒，期间轮询锁状态，一旦释放立刻抢占；适合强串行化逻辑，例如支付回调幂等处理或库存扣减。
注意：不要在 block() 内部调用外部 HTTP 请求或长事务——锁 TTL 到期后你还在等，别人已闯入。
锁键命名与 TTL 设置有讲究
键名建议包含三要素：业务域 + 唯一标识 + 环境前缀，例如 stock:product_456:prod。避免不同环境共用同一把锁造成误干扰。
TTL 不是拍脑袋定的 30 秒，而应大于 95% 场景下的实际执行耗时。可通过日志埋点统计闭包内耗时，再设值。TTL 过短会导致锁提前释放，后续请求闯入；过长则拖慢整体响应。
闭包中若抛出未捕获异常，Laravel 会自动释放锁；但如果用了 try-catch 吞掉异常又没手动 del，锁将滞留至过期，卡住后续请求。
缓存锁 ≠ 数据库锁，最终一致性要靠行锁兜底
Cache::lock() 只管“谁先拿到锁”，不管“谁改得对”。多个请求都抢到锁后各自查 DB、改余额、再写回，仍可能超卖。
正确做法是：锁内务必结合数据库行锁。例如：
Cache::lock('stock:product_456', 10)->block(5)->get(function () use ($productId, $quantity) {
DB::transaction(function () use ($productId, $quantity) {
$stock = DB::table('stocks')
->where('product_id', $productId)
->lockForUpdate() // 强制加行锁
->first();
if ($stock->available >= $quantity) {
DB::table('stocks')
->where('product_id', $productId)
->decrement('available', $quantity);
}
});
});
这样既利用缓存锁快速分流，又靠数据库行锁确保数据修改的排他性。
