并发请求会放大n+1问题代价，需确保with()链式调用、避免访问器触发懒加载、优先用withcount()替代with()、事务外预加载、为嵌套关系添加外键索引。
并发请求本身不会“引发”N+1问题，但会让N+1的代价指数级放大：10个并发请求各触发20次懒加载，就是200次重复查询。真正要防的，是多个请求共享同一段未优化的关联访问逻辑。
with() 必须在 get() 前调用，且不能藏在闭包或条件分支里
并发场景下，代码路径更复杂，容易把 with() 写错位置或漏掉分支。比如在 API 控制器中根据参数决定是否加载头像：
- 错误写法：
$posts = Post::query(); if ($request->with_avatar) { $posts->with('avatar'); } $posts->get();——with()被忽略，因为没链式返回新实例 - 正确写法：
$posts = Post::query()->when($request->with_avatar, fn ($q) => $q->with('avatar'))->get(); - 更稳妥的是统一预加载再裁剪字段：
Post::with(['avatar' => fn ($q) => $q->select('id', 'url')])->get()，避免分支遗漏
别在模型访问器（accessor）里触发关联查询
并发时每个请求都走一遍访问器，而访问器里写 $this->user 就等于埋了 N+1 雷。常见于封装「作者名」字段：
- 危险 accessor：
public function getAuthorNameAttribute() { return $this->user->name ?? ''; } - 它绕过所有
with()，即使你写了Post::with('user')->get()，访问器仍会懒加载一次 - 解法：改用
isset($this->relations['user']) ? $this->user->name : null，或直接在查询时用selectRaw()拼接
分页 + with() 是安全的，但 withCount() 更轻量
并发接口常带分页，Post::with('user')->paginate(20) 是合法且推荐的，它只预加载当前页 20 条数据的 user，不是全表。但如果你只需要「作者名」和「评论数」，就别用 with('user', 'comments')：
-
withCount('comments')生成COUNT(*)子查询，返回$post->comments_count，无内存膨胀 -
with('user')却会拉取完整 user 记录，哪怕你只显示$post->user->name - 高并发下字段越精简越好：
Post::with(['user' => fn ($q) => $q->select('id', 'name')])->paginate(20)
事务内禁止 with()，提前查或改用 join
并发请求若涉及写操作（如批量点赞），常套在 DB::transaction() 里。此时在事务块内调用 with() 不仅无效，还可能因锁竞争拖慢整个队列：
- 错误：
DB::transaction(function () { $posts = Post::with('user')->get(); ... }); - 正确做法一（推荐）：
$posts = Post::with('user')->whereIn('id', $ids)->get(); DB::transaction(fn () => { ... }); - 正确做法二（读写分离）：事务内只用
DB::table('posts')->join('users', ...)->select(...)->get()，彻底绕过 Eloquent 懒加载路径
最隐蔽的坑是嵌套关系拼错或外键没索引——with('user.profile') 看似正常，但若 profile 表缺 user_id 索引，IN 查询会变全表扫描，10 个并发就压垮数据库。务必用 DB::enableQueryLog() 抓真实 SQL，别信“写了 with 就万事大吉”。
