hasManyThrough 是单次 JOIN 查询远程关联的只读方案，适用于 A→B→C 两跳外键明确场景；需显式传参适配非标准字段名，支持 whereHas 过滤与 withCount 计数，但不支持三跳预加载、写操作及中间模型字段直取。
远程关联不是跨数据库，也不是调用 API，而是用 hasManyThrough 或 hasOneThrough 在单次 SQL 查询中跳过中间模型拿到远端数据——它只在 A→B→C 路径明确、外键存在且稳定时才有效。
什么时候必须用 hasManyThrough，而不是嵌套循环
当你需要从 Country 直接拿到所有 Post，且不想写 $country->users->flatMap(fn($u) => $u->posts) 这种低效代码时，hasManyThrough 是唯一正解。它生成一条带 JOIN 的 SQL，一次查出全部，避免 N+1 和内存膨胀。
- 中间模型（如
User）必须有指向主模型（Country）的外键，比如users.country_id - 远端模型（如
Post）必须有指向中间模型（User）的外键，比如posts.user_id - 若路径超过两跳（A→B→C→D），
hasManyThrough不支持，得拆成两步或手写子查询
外键字段名不标准？参数顺序必须对齐
hasManyThrough 默认只认 id、user_id、country_id 这类命名。只要有一个字段非默认，就必须显式传参，否则 JOIN 条件会错，结果为空或笛卡尔积。
- 第三个参数是「中间模型里指向当前模型的外键」，即
User表中存CountryID 的字段名，例如'nation_id' - 第四个参数是「远端模型里指向中间模型的外键」，即
Post表中存UserID 的字段名，例如'author_id' - 第五个参数是当前模型的主键名（默认
'id'，若用uuid则需显式传'uuid'） - 错误示例：
hasManyThrough(Post::class, User::class, 'region_id')—— 漏了第四个参数，SQL 仍会用posts.user_id去 JOIN，但表里实际是author_id
whereHas 过滤远程关联数据的写法陷阱
想查「状态为 published 的国家文章」，不能对 posts 关系直接 where()，因为 posts 不是主表字段；必须用 whereHas，它会把条件注入到 JOIN 子句中。
- 正确：
Country::whereHas('posts', fn($q) => $q->where('published', 1))->get() - 错误：
Country::with('posts')->where('posts.published', 1)->get()—— 报错Unknown column 'posts.published' - 错误：
Country::with(['posts' => fn($q) => $q->where('published', 1)])—— 这只是限制预加载结果，不影响主查询，查出来的Country仍是全部
预加载和计数的边界在哪
with('posts') 可以预加载，但 with('posts.user') 会静默失败，因为 hasManyThrough 不支持三跳嵌套。而 withCount('posts') 是安全的，它生成子查询，比全量预加载更轻量。
- 不能对远程关联做写操作：
sync()、attach()、detach()全部无效，hasManyThrough是只读穿透查询 - 中间模型字段（如
cities.approved_at）无法直接取到，要访问就得selectRaw或改用视图 - 如果中间模型本身没索引（比如
users.nation_id缺少索引），JOIN 性能会断崖式下降，查大表时可能超时
