N+1查询指主查询N条数据后，为每条数据单独发起1次关联查询，共N+1次SQL；ThinkPHP中典型表现为日志里出现N条结构相同、仅ID值不同的SELECT语句，开启'show_sql'=>true可直接识别。
什么是N+1查询，ThinkPHP里怎么一眼认出来
ThinkPHP里出现N+1，典型表现是：查10条用户数据，接着又自动发起10次SQL去查每个用户的关联文章——总共11条SQL，但后10条结构几乎一样，只是user_id值不同。这种问题在with()没用对、或用了relation()但没触发预加载时高频发生。
关键识别点：日志里反复出现同一张表的SELECT ... WHERE xxx_id = ?语句，且数量等于主查询结果数。
- 开启SQL日志（
'show_sql' => true）是最直接的判断方式 - 不要只看代码写了
with('posts')就以为安全——如果后续又调用了$user->posts->title之类未缓存的访问，仍可能触发懒加载 - 关联模型没定义
foreignKey或localKey，with()会失效，退化为N+1
with()预加载必须配对使用关联定义
with()不是万能开关，它依赖模型里提前声明的关联方法。比如用户模型要预加载文章，必须有对应的方法：
class User extends Model
{
public function posts()
{
return $this->hasMany(Post::class, 'user_id', 'id');
}
}
然后才能安全调用：User::with('posts')->select()。漏掉posts()方法，或参数写错（比如把'user_id'写成'uid'），with()就静默失效。
立即学习“PHP免费学习笔记（深入）”；
- 关联方法名必须和
with()里的字符串完全一致（区分大小写） - 一对多场景下，
hasMany的第三个参数localKey默认是'id'，但如果主键不是id（如'user_id'），必须显式指定 - 一对一（
hasOne）和属于（belongsTo）同理，参数顺序和含义容易颠倒，建议对照文档核对
嵌套预加载与闭包过滤的正确写法
需要查「用户 + 文章 + 文章分类」三层关联时，不能写成with(['posts.category'])就完事——如果category关联没在Post模型里正确定义，依然会N+1。更危险的是，在闭包里做条件过滤却忘了加field限制：
User::with(['posts' => function ($query) {
$query->where('status', 1)->field('id,title,user_id'); // 必须加field，否则查出全部字段拖慢性能
}])->select();
- 嵌套语法
['posts.category']要求Post模型存在category()方法，且该方法返回的关联对象本身也支持预加载 - 闭包里不加
field()，即使主表只取3个字段，关联表仍可能查出20+字段，内存和网络开销陡增 - 避免在
with()闭包里调用limit()——ThinkPHP 6.0+对关联limit支持不稳定，容易导致主表数据被意外截断
count()、find()、paginate()场景下的特殊陷阱
很多人以为with()对所有查询都生效，其实不然：count()和find()默认不走预加载；paginate()在开启simple模式时，with()可能被忽略。
-
User::with('posts')->count()→ 只查用户总数，posts完全不参与，with()被丢弃 -
User::with('posts')->find(1)→ ThinkPHP 6.0.13之前版本，find()不触发with()，需改用findOrFail()或手动load() -
paginate()若配置'simple' => true，底层用count()+limit分页，此时with()仅作用于数据查询，不作用于count查询——但count本身不需要关联数据，所以实际无影响；真正风险在于你误以为分页结果里的关联数据已加载，结果模板里一访问就触发懒加载
复杂关联+分页时，最稳的方式是先select()拿到ID数组，再用whereIn('user_id', $ids)单独查关联数据，手动组装——虽然多写几行，但逻辑可控，不会掉坑里。
