laravel锁机制需对齐业务场景的粒度、持有时间和失败兜底逻辑；lockforupdate()须配合db::transaction()使用，cache()->lock()的key须含业务标识并设合理ttl，乐观锁需显式校验version字段。
直接说结论：Laravel 的锁机制不是“配个参数就完事”，关键在**锁的粒度、持有时间、失败兜底逻辑**三者必须对齐业务场景。用错 lockForUpdate() 或 cache()->lock()，比不用还危险。
lockForUpdate() 必须和 DB::transaction() 一起用，否则等于没锁
常见错误是写成 Order::find(123)->lockForUpdate() —— 这根本不会加锁，因为 find() 已经执行完查询，lockForUpdate() 调用时早已脱离事务上下文。
- 正确写法只能是
Order::where('id', 123)->lockForUpdate()->first()，且整个操作必须包裹在DB::transaction()闭包内 - MySQL 的
SELECT ... FOR UPDATE是行级写锁，会阻塞其他事务对同一行的UPDATE和再次FOR UPDATE，但不阻塞普通SELECT - 如果 WHERE 条件没走索引，MySQL 会升级为表锁，瞬间拖垮并发能力——务必确认执行计划里有
key字段 - 事务内不要做 HTTP 请求、文件读写、sleep() 等耗时操作，锁持有时间越长，排队越严重
cache()->lock() 的 key 必须带业务标识，不能写死
写成 cache()->lock('order_lock') 是典型反模式：所有订单共用一个锁，高并发下变成单线程处理，吞吐量归零。
Laravel 13.2.0
下载
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
- key 应包含唯一业务维度，例如
'order_lock:'. $orderId或'stock_lock:'. $skuId - 若 $orderId 来自用户输入，先做
urlencode()或md5()处理，避免特殊字符破坏 Redis key 结构 - ttl（过期时间）别依赖默认 10 秒——网络抖动或慢 SQL 可能超时，建议按操作预期耗时 × 2 设置，比如预计更新要 3 秒，设为 6–10 秒
- 别只靠
lock()->get()返回true/false判断成败；应配合block(3)或手动重试逻辑，防止因瞬时失败误判
乐观锁适合读多写少，但 version 字段必须参与 WHERE 条件
很多团队加了 version 字段却没在更新时校验，等于白加。Eloquent 默认的 save() 不会自动带上 version 比较。
- 更新必须显式写成
Account::where('id', $id)->where('version', $expectedVersion)->update([...]) - 如果
affected rows === 0，说明版本已变，需重新读取最新数据再重试，不能直接覆盖 - 乐观锁不加数据库锁，性能好，但重试逻辑得自己写清楚——别让前端一直转圈等超时
- 不适合库存扣减这类“必须串行”的场景，因为重试可能失败多次，用户体验差；这种地方悲观锁更稳
死锁重试不能只靠 DB::transaction($callback, 3)，得控制重试行为
DB::transaction() 的第二个参数确实会捕获 MySQL 错误码 1213 并重试，但前提是闭包内操作是幂等的。否则重试三次可能扣三次库存。
- 重试前先检查是否已部分成功（比如日志表已写入、消息已发），避免重复动作
- 统一更新顺序：比如所有涉及
orders和inventory的事务，强制先锁orders行再锁inventory行，从根源减少死锁概率 - 需要精细控制时，改用
DB::beginTransaction()+ 手动commit()/rollback()，并在 catch 中判断$e->getCode() === '1213' - 重试次数别设太高（一般 2–3 次足够），超过就抛异常交由队列或告警系统处理，卡住不如快失败
最易被忽略的一点：锁只是手段，不是目的。真正该花时间做的，是识别哪些操作真需要强一致性（比如支付扣款），哪些可以接受短暂不一致（比如浏览计数）。过度锁，比不锁更伤性能。
