一对多关系中，Post模型用belongsTo(User::class)因posts表含user_id外键，User模型用hasMany(Post::class)；预加载用with()防N+1，whereHas支持关联表条件筛选，关联更新须调用关联方法而非直接save()。
一对多关系怎么在模型里写？
关键不是“怎么定义”，而是“谁 belongsTo 谁”——Laravel 的关联方向必须和数据库外键位置严格一致。比如 posts 表有 user_id 字段，那 Post 模型才该用 belongsTo(User::class)；反过来，User 模型写 hasMany(Post::class) 才对。
常见错误现象：Call to undefined relationship 或查出空集合，八成是外键字段名没对上、或者模型里写反了方向。
-
hasMany()写在「一」方（如User），返回集合，外键默认在「多」方表里（posts.user_id） -
belongsTo()写在「多」方（如Post），返回单个模型，Laravel 默认按当前模型名加_id推导外键（即post.user_id→ 实际要的是post.user_id，不是post.author_id） - 如果外键不是默认名（比如叫
author_id），belongsTo()必须显式传第二个参数：belongsTo(User::class, 'author_id')
关联查询时 N+1 问题怎么破？
直接用 $user->posts 看似简单，但循环里反复调用就会触发 N+1：查 1 个用户 + 查 N 次 posts。性能掉得特别快，尤其列表页。
正确做法永远是预加载。不是等要用才取，而是在主查询时就声明依赖：
User::with('posts')->get();
注意点：
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
with()只解决「读取时」的 N+1，不改变底层 SQL 关联逻辑；它本质是两条独立查询（先查 users，再查 in(ids) 的 posts） - 如果真需要 JOIN（比如按 posts 字段排序或筛选），得用
join()+select()，不能依赖with() - 嵌套预加载写法是
with(['posts.comments'])，但别无脑嵌套——每多一层，查询复杂度指数增长
whereHas 和 has 有什么区别？
whereHas() 是「带条件查主模型」，has() 是「只看有没有关联，不筛内容」。比如查「发过评论的用户」，用 has('comments') 就够；但查「发过含‘bug’评论的用户」，必须用 whereHas('comments', fn ($q) => $q->where('content', 'like', '%bug%'))。
容易踩的坑：
-
has()不支持闭包条件，只能传关系名和操作符（如has('posts', '>=', 5)） -
whereHas()的闭包里写的where是对关联表字段生效，不是主表——新手常在这里写错字段归属 - 两者都走 EXISTS 子查询，大数据量时注意索引：关联字段（如
comments.post_id）必须有索引，否则慢得明显
关联数据更新时为什么 save() 不生效？
因为 Eloquent 的关联对象不是普通属性，不能直接改完 save()。比如 $user->posts[0]->title = 'new'; $user->posts[0]->save(); 看似合理，但其实绕过了模型事件和批量处理逻辑，且容易漏掉时间戳、软删除等自动行为。
更稳的方式：
- 用关联方法本身更新：
$user->posts()->where('id', 123)->update(['title' => 'new']) - 或者先取模型再改：
$post = $user->posts()->find(123); $post->title = 'new'; $post->save(); - 批量新增用
saveMany()，别一个个save()；删除用posts()->delete()，别循环调用$post->delete()
最常被忽略的一点：关联查询返回的集合是「只读快照」，不是实时绑定的引用。改完 $user->posts 里的对象，不会自动同步到数据库——必须显式调用对应关联的写操作方法。
