DB::transaction() 高并发卡住主因是默认隔离级别下更新同行触发行锁且锁持续至提交，导致阻塞或死锁；应精简事务、显式加锁、原子更新、合理设超时，并按场景选悲观/乐观锁。
为什么 DB::transaction() 在高并发下会卡住甚至超时
不是事务本身慢，而是默认的数据库隔离级别（如 MySQL 的 REPEATABLE READ）在更新同一行时会触发行级锁，并且锁会持续到事务提交。如果多个请求同时执行 DB::transaction() 并试图更新同一条记录（比如库存扣减），后到的请求就会被阻塞，直到前一个事务释放锁——这直接导致响应延迟甚至 Illuminate\Database\QueryException: SQLSTATE[HY000]: General error: 1205 Deadlock found。
实操建议：
- 避免在事务中做耗时操作（如 HTTP 请求、文件读写、循环计算），只保留必要 DB 操作
- 把
SELECT ... FOR UPDATE放在事务最开始，且尽量缩小 WHERE 条件范围（比如用主键而非模糊查询） - 设置合理事务超时：MySQL 可调
innodb_lock_wait_timeout（默认 50 秒），Laravel 中可通过DB::connection()->getPdo()->setAttribute(PDO::ATTR_TIMEOUT, 5)控制连接级超时（注意这不是锁等待超时） - 用
DB::select('SELECT * FROM products WHERE id = ? FOR UPDATE', [$id])显式加锁比Product::lockForUpdate()->find($id)更可控，后者可能因 Eloquent 的 lazy loading 触发额外查询而延长锁持有时间
用 DB::update() 原生更新代替 Model->save() 避免 N+1 锁竞争
当多个请求并发更新同一商品库存，若都走 $product = Product::find($id); $product->stock--; $product->save();，每个请求都会先 SELECT 再 UPDATE，中间有时间窗口，且 Eloquent 会加载整行再改——这不仅放大锁范围，还可能因模型事件、访问器等引入不可控延迟。
更安全的做法是原子性更新：
DB::update('UPDATE products SET stock = stock - 1 WHERE id = ? AND stock >= 1', [$id]);
这个语句自带条件检查和原子扣减，失败时返回 0 行影响，无需加锁也无竞态。适用场景：简单字段变更、带前置条件的更新（如“余额足够才扣款”）。
注意点：
- 不能触发 Eloquent 的
updating或updated事件，需自行处理日志或通知 - 无法自动填充
updated_at，得显式写入：SET updated_at = NOW(), stock = stock - 1 - 若需返回影响行数做业务判断，用
DB::affectingStatement()替代DB::update()（后者不抛异常但也不返回值）
乐观锁方案：用 version 字段 + WHERE version = ? 实现无阻塞重试
适合读多写少、冲突概率低的场景（如文章阅读量、用户积分）。核心思路是不锁行，靠版本号检测并发修改，失败后由应用层决定是否重试。
示例结构：
