hasManyThrough 返回空数组主因是字段名不匹配默认约定，需检查中间模型外键、远端模型外键及当前模型主键名；填参须严格按 JOIN 路径顺序，漏掉第5参数（本模型主键名）是高频错误；中间表需条件过滤时应换方案；预加载存在JOIN膨胀与N+1风险，需谨慎评估。
hasManyThrough 返回空数组，先检查这三处字段名
绝大多数空结果不是逻辑写错，而是外键字段名和 Laravel 默认约定不一致。它不会报错，只会静默返回空集合。
需要逐个确认：
表里指向当前模型的字段名（比如
，而不是默认的
）
表里指向中间模型的字段名（比如
，而不是默认的
）
当前模型的主键名（比如
或
，不是
）
只要其中任一字段名不匹配，
就查不到数据。别依赖“自动推断”，显式传参最稳。
五个参数怎么填才不漏、不错位
签名是
，但前四个最常用，后两个容易被忽略。
填参顺序必须严格对应 JOIN 路径：
第 1 个参数：远端模型完整类名，如
（不能只写
）
第 2 个参数：中间模型完整类名，如
第 3 个参数：中间模型上“指向本模型”的字段，即
→
第 4 个参数：远端模型上“指向中间模型”的字段，即
→
第 5 个参数：本模型主键名，如
（默认是
，但用了就一定要写）
漏掉第 5 个参数是高频翻车点——哪怕中间表和远端表字段都对了，主键不是
也会查不到。
中间表有状态过滤或软删除？别硬套 hasManyThrough
底层是纯 JOIN 查询，没法给中间模型加
条件。一旦中间表要筛
或跳过
的记录，它就失效了。
Laravel 13.2.0
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
下载
这时该换方案：
用
+ 自定义中间表查询（适合中间是多对多）
手动写子查询或
显式 JOIN 并加条件
在模型里定义普通
关系，再用集合方法
手动聚合（适合数据量不大）
强行在
后链式调用
是无效的——它不会下推到中间表，只会查出全部再内存过滤。
预加载时 hasManyThrough 的 N+1 风险比想象中高
表面上看
能一次查完，但实际执行的是三表 JOIN，如果中间模型数据量大，生成的 SQL 可能爆炸式膨胀。
更隐蔽的问题是：当同时预加载多个
关系（比如
和
），Eloquent 会为每个关系单独发 JOIN 查询，而不是合并。结果可能比 N+1 还慢。
建议：
用
打印生成的 SQL，确认 JOIN 数量和字段是否合理
对大数据量场景，优先考虑应用层分步查（先查中间模型 ID 列表，再查远端模型）
避免在同一个
中混用
和普通
，容易触发意外笛卡尔积
真正难的从来不是写对那几行定义，而是想清楚 JOIN 是否真适合你的数据分布和查询频率。
中间模型posts.author_iduser_id远端模型comments.article_idpost_iduuidcodeidhasManyThroughhasManyThroughhasManyThrough($through, $via, $firstKey, $secondKey, $localKey, $secondLocalKey)App\Models\Comment::classCommentApp\Models\Post::classposts.author_idusers.uuidcomments.article_idposts.iduuidididhasManyThroughWHEREstatus = 'published'deleted_at IS NOT NULLbelongsToManyDB::table()hasManyflatMaphasManyThroughwhereHas('intermediate', ...)Country::with('posts')hasManyThroughpostscommentstoSql()with()hasManyThroughhasMany