tp8.0模型关联查询性能差主因是n+1问题，即每条主记录触发一次关联查询；需通过sql日志确认，with()必须在select()前调用才生效，推荐用批量in预加载或分两步查+内存关联解决。
TP8.0 模型关联查询性能差，往往不是数据库慢，而是代码每查一条主记录就额外发起一次关联查询——100 条用户数据触发 100 次 profile 查询，SQL 日志里密密麻麻全是重复的 SELECT * FROM profile WHERE user_id = ?，响应时间从 200ms 暴涨到 3s 以上。
确认 N+1 是否真实存在
打开 SQL 日志开关：在 config/database.php 中设 【'show_sql' => true】，刷新列表页，观察日志中 SELECT 语句数量。若主表查了 1 条，却冒出 50 条形如 SELECT * FROM article WHERE user_id = ? 的语句，就是典型的 N+1。
别信“with 已写了”，必须验证——with() 必须写在 select() 之前才生效，UserModel::select()->with('articles') 完全无效。
基础预加载：单层、多层、嵌套
第一步：确保模型已正确定义关联方法，例如 UserModel 中有 public function articles() { return $this->hasMany(ArticleModel::class, 'user_id', 'id'); }。
第二步：调用 with() 并传入字符串或数组，立即执行查询：
UserModel::with('articles')->select() → 查出全部用户，并用一条 IN 查询批量拉取所有关联文章；
UserModel::with(['articles', 'profile'])->select() → 同时预加载两层独立关联。
第三步：嵌套必须显式写到叶子节点，UserModel::with('articles.category')->select() 要求 ArticleModel 内存在 category() 关联方法，否则 category 字段访问时仍会补查。
闭包控制：字段、条件、数量
方法一：精简字段，避免传输冗余
UserModel::with(['articles' => function ($q) { $q->field('id,title,user_id,status'); }])->select()
方法二：加 where 过滤关联数据范围
UserModel::with(['articles' => function ($q) { $q->where('status', 1)->order('created_time', 'desc'); }])->select()
方法三：限制条数防内存爆炸
UserModel::with(['articles' => function ($q) { $q->limit(5); }])->select()
注意：limit 在分页场景下慎用，它作用于每个用户的前 5 篇文章，而非全局 Top5
一对多关联的 N+1 正确解法
第一步：用 with() 配合批量 IN 查询是最常用路径，但仅适用于关联数据量可控（如每人最多 20 条订单）的场景。
第二步：若关联数据极多（如日志表、消息表），改用「分两步查 + 内存关联」：
UserModel::select() → 获取 $users 集合；
$userIds = array_column($users, 'id');
OrderModel::where('user_id', 'in', $userIds)->select() → 一次性查出全部订单；
最后用 PHP 循环挂载：
foreach ($users as &$u) { $u->orders = $orders->filter(fn($o) => $o->user_id == $u->id); }
这一步绕过 with 的惰性机制，彻底消灭 N+1，且不依赖 JOIN 字段别名冲突或数据膨胀问题。
集合对象上延迟加载关联
当已查出 $users = UserModel::all([1,2,3,4,5])，但临时需要补载 profile 数据时：
直接调用 $users->load('profile') —— ThinkPHP 会合并为一条 IN 查询：SELECT * FROM profile WHERE user_id IN (1,2,3,4,5)。
千万别在 foreach 里逐条调用 $user->load('profile')，那等于回到 N+1。
