load() 总查 N+1 次，因其默认即时触发、无缓存、每次调用单独发 SQL；适合单实例偶发加载，不适用于批量场景，且不支持条件过滤与深度序列化。
ThinkPHP 模型里 load() 方法为什么总查 N+1 次？
因为 load() 默认是「即时触发」的，每次调用都单独发一次 SQL，哪怕你已经在循环里反复查同一个关联字段。它不感知上下文，也不缓存中间结果，本质就是个语法糖包装的单条关联查询。
常见错误现象：foreach ($users as $user) { $user->load('profile'); } —— 用户列表 100 条，就发 101 条 SQL（1 条主表 + 100 条 profile）。
- 它只适合单个模型实例的偶发性关联加载，不适合批量场景
- 参数上不支持条件过滤（比如
load('posts.status=1')是无效的） - 返回值是当前模型对象本身，但内部关联数据只是临时塞进属性，不参与后续的序列化或 toArray() 的深度处理
延迟预载入（with()）怎么写才不漏查、不重复？
with() 是解决 N+1 的正解，但它不是“写了就完事”，关键在调用时机和嵌套层级控制。
正确姿势是：在主查询构建阶段就声明关联，而不是查完再补。例如：UserModel::with(['profile', 'posts' => function ($q) { $q->where('status', 1); }])->select();
立即学习“PHP免费学习笔记（深入）”；
- 多个关联用数组传，顺序无关，TP 会自动合并为 JOIN 或 IN 查询
- 闭包里只能做 where/order/limit，不能调用
find()或select()，否则会退化成多次子查询 - 深层嵌套如
with(['posts.comments.user'])要小心：TP 6.0+ 支持，但 5.1 只到二级，三级会静默失败或报错Relation not exists - 如果关联模型用了软删除，记得在关联定义里加
->withTrashed()，否则with()查不到已软删的数据
load() 和 with() 混用时，哪些地方会悄悄覆盖或失效？
混用本身不报错，但行为不可控：后调用的会覆盖前者的关联数据，且 load() 的结果不会被 with() 的缓存机制识别。
典型翻车现场：$user = UserModel::find(1)->load('profile'); $user->with(['posts'])->select(); —— 第二行根本不会生效，因为 with() 是构造器方法，必须在 find() 或 select() 前链式调用。
-
load()返回的是模型实例，而with()返回的是查询器实例，类型不同，不能链式混搭 - 已经用
with()查过的集合，再对其中某个模型调用load()，会重新查一遍数据库，不走内存缓存 - 使用
toArray()时，只有with()加载的数据会被递归转出；load()加载的字段默认不包含，除非手动设置visible或重写toArray()
性能敏感场景下，with() 的 IN 查询 vs JOIN 查询怎么选？
TP 默认对 hasMany/belongsTo 用 IN 查询（先查主表 ID，再用 WHERE id IN (...) 查关联），对 belongsTo 有时会自动优化为 JOIN —— 但这取决于关联定义是否明确指定了外键字段。
容易被忽略的一点：当主表数据量大、关联表有索引但 IN 列表超长时（比如 2000+ ID），MySQL 可能放弃索引走全表扫描。这时候得手动切 JOIN：
- 在关联定义里加
'join_type' => 'LEFT'（TP 6.0.13+ 支持） - 或者改用
relation('profile')->join(true)强制 JOIN - JOIN 更适合小数据集+强关联场景；IN 更适合大数据集+弱关联（避免笛卡尔积）
- 测试时别只看 SQL 条数，用
EXPLAIN看实际执行计划，特别是type和rows字段
复杂点在于：JOIN 后字段名可能冲突（比如两个表都有 id），TP 默认用 关联名_字段名 做别名，但如果你在闭包里用了 field()，就得自己处理别名，不然取不到数据。
