应使用多对多多态关联（favorites表），而非布尔字段或冗余字段；需加联合唯一索引、正确拼写、配置模型可填充属性；收藏数用原子计数器+索引优化，避免n+1和缓存不一致。
收藏功能该用多对多还是布尔字段
多数人一上来就建 user_favorites 中间表，但真没必要——除非你后续要存收藏时间、排序权重、分类标签等扩展信息。如果只是“用户是否收藏过某篇文章”，直接在 posts 表加个 is_favorited_by_user_id 字段？不行，会爆炸式冗余。正确做法是坚持多对多：一张 favorites 表（字段仅需 user_id 和 favoritable_id + favoritable_type），支持跨模型复用（文章、视频、商品都能被收藏）。
容易踩的坑：
• 忘记加联合唯一索引：ALTER TABLE favorites ADD UNIQUE(user_id, favoritable_id, favoritable_type)，否则同一用户可能重复收藏；
• 用 favoriteable_id 拼写错误导致迁移失败或查询为空；
• 在模型里没声明 $fillable 或没设 protected $guarded = []，导致 Favorite::create() 静默失败。
Laravel 的 polymorphic pivot 怎么写模型关系
收藏目标不固定（可能是 Post、Video），必须用多态关联。核心不是“怎么定义”，而是“怎么避免每次都要手写 where 条件”。在 User 模型里加：
public function favorites()
{
return $this->morphToMany(FavoriteTarget::class, 'favoritable')
->using(Favorite::class)
->as('favorite')
->withTimestamps();
}
但更实用的是反向定义：在 Post 模型里写一个 isFavoritedBy($user) 方法：
public function isFavoritedBy($user): bool
{
return $this->favorites()->where('user_id', $user->id)->exists();
}
注意点：
• Favorite 中间模型必须继承 Pivot，且不能有主键（Laravel 默认不为 pivot 模型生成 ID）；
• 如果用了 SoftDeletes，记得在 Favorite 表里也加 deleted_at 并在关系中启用 withTrashed()，否则软删除用户后收藏记录查不到；
• 不要用 belongsToMany 直接关联 User 和 Post，那会锁死模型类型，失去多态意义。
前端点击收藏按钮时后端怎么防重复提交
用户狂点“收藏”按钮，后端不能靠 JS 禁用按钮兜底——网络延迟、刷新、多开标签都会绕过。真正的防护在服务端：用数据库唯一约束兜底，再配合应用层判断。
推荐写法：
• 先查是否存在：Favorite::where(['user_id' => auth()->id(), 'favoritable_id' => $postId, 'favoritable_type' => Post::class])->exists()；
• 存在则返回 200 + {"status": "already_favorited"}；
• 不存在则用 Favorite::create(...)，捕获 Illuminate\Database\QueryException（触发唯一索引冲突时抛出），统一转成 409 响应；
• 别用 firstOrCreate()，它在高并发下仍有极小概率插入两条（因 SELECT 和 INSERT 非原子）。
性能影响：
• 单次收藏操作最多 2 次查询（先查后插），比单纯 create() 多一次，但换来确定性；
• 如果并发量极大（如秒杀级收藏），可加 Redis 锁（Cache::lock("fav_{$user->id}_{$postId}", 10)），但绝大多数项目没必要。
收藏数统计怎么避免 N+1 和实时性陷阱
文章页显示“已收藏 248 次”，别在循环里调 $post->favorites->count()——这是典型 N+1。也不建议用 withCount('favorites') 后再手动加缓存，因为 withCount 默认走 COUNT(*)，没走索引会慢。
务实方案：
• 在 posts 表加 favorites_count 字段，收藏/取消收藏时用 increment() / decrement() 原子更新；
• 查列表时直接 select('posts.*', 'posts.favorites_count')，零额外查询；
• 取消收藏逻辑必须严格校验：只有当前用户确实收藏了，才允许 decrement，否则可能负数；
• 索引要覆盖：ALTER TABLE favorites ADD INDEX idx_fav_type_id (favoritable_type, favoritable_id)，否则 count 查询会全表扫。
容易被忽略的地方：缓存失效时机。如果用 Redis 缓存了某个文章的收藏数，increment() 后必须同步 Cache::decrement() 或删缓存，否则缓存和 DB 不一致——而这个动作常被漏掉，尤其在队列任务里处理取消收藏时。
