本文介绍如何在 laravel 中通过单次数据库查询，高效获取当前用户发布的帖子、所关注用户发布的帖子以及自己分享的帖子，避免 n+1 查询问题并提升性能。
本文介绍如何在 laravel 中通过单次数据库查询，高效获取当前用户发布的帖子、所关注用户发布的帖子以及自己分享的帖子，避免 n+1 查询问题并提升性能。
在构建社交类应用（如动态流 Feed）时，常需聚合三类内容：当前用户原创的帖子（posts）、其关注的用户发布的帖子（followers_posts），以及该用户主动分享的他人帖子（shared_posts）。若分别查询再合并，不仅逻辑冗余，还易引发 N+1 问题或数据排序混乱。Laravel 的 hasManyThrough 关系与预加载（Eager Loading）可优雅解决此需求。
✅ 正确建模关联关系
首先，在 User 模型中明确定义四类关联（注意字段名与外键一致性）：
// app/Models/User.php
public function posts()
{
return $this->hasMany(Post::class, 'user_id', 'id');
}
public function followers()
{
return $this->hasMany(Follower::class, 'user_id', 'id'); // 当前用户作为被关注者
}
// 获取「我关注的人」发布的帖子 → 通过 followers 表中 follower_id = auth()->id() 查找 user_id，再查 posts
public function followers_posts()
{
return $this->hasManyThrough(
Post::class,
Follower::class,
'user_id', // Follower 表中指向被关注用户的外键（即关注谁）
'user_id', // Post 表中外键，关联发布者
'id', // User 表主键（当前用户 ID）
'follower_id' // Follower 表中指向关注者的外键（即“我”）
)->where('followers.follower_id', auth()->id()); // 关键：限定只取“我”关注的人的帖子
}
// 获取「我分享的帖子」→ SharedPost 表中 user_id = auth()->id()，关联到 post_id 对应的 Post
public function shared_posts()
{
return $this->hasManyThrough(
Post::class,
SharedPost::class,
'user_id', // SharedPost 外键：谁分享的
'id', // Post 主键（shared_posts.post_id 指向 posts.id）
'id', // User 主键
'post_id' // SharedPost 外键：分享了哪篇帖子（对应 posts.id）
)->where('shared_posts.user_id', auth()->id());
}⚠️ 注意：hasManyThrough 的参数顺序易混淆。务必确认中间表（Follower / SharedPost）的外键含义，并使用 where() 显式约束当前用户身份，否则会拉取全部关联数据。
✅ 单次查询 + 预加载整合数据
不推荐在控制器中拼接多个 UNION 查询（复杂且难维护），而应利用 Eloquent 预加载一次性获取所有关联集合，再在 PHP 层合并、去重、排序：
// 在控制器中（如 HomeController@index）
$user = auth()->user();
$aggregatedPosts = collect()
->merge($user->posts)
->merge($user->followers_posts)
->merge($user->shared_posts)
->unique('id') // 去重：防止同一篇帖子因多种关系重复出现（如自己发又自己分享）
->sortByDesc('updated_at') // 统一按更新时间倒序
->values(); // 重置键名，返回数值索引集合
return view('home', compact('aggregatedPosts'));✅ 优势：
- 数据库仅执行 1 次主查询 + 3 次 JOIN 预加载（共 4 次查询，非 N+1）；
- 逻辑清晰，便于后续扩展（如添加点赞数、阅读状态等）；
- collect()->merge() 灵活可控，支持自定义去重策略（如按 id 或 (post_id, type) 复合键）。
⚠️ 注意事项与优化建议
- 分页处理：上述方案在数据量大时无法直接分页（因合并发生在 PHP 层）。如需分页，应改用 UNION ALL 原生查询或数据库视图，或采用 Laravel Scout + Algolia 等搜索方案；
- 模型命名规范：确保 Follower 和 SharedPost 模型已正确创建，且表名与迁移一致（如 shared_posts 而非 shares）；
- 权限校验：shared_posts 关系默认返回所有分享记录，生产环境应结合 Post 的可见性逻辑（如 is_public 字段）做二次过滤；
- 性能监控：使用 Laravel Debugbar 或 DB::enableQueryLog() 验证实际 SQL，避免意外触发额外查询。
通过合理设计模型关系与善用集合操作，你能在保持代码简洁性的同时，交付高性能、可维护的动态流功能。
