多态关联用于同一子模型需被多个不相关父模型复用的场景，如评论、点赞、附件等；必须配合联合唯一索引防重复，并注意morphTo/morphMany参数与数据库字段前缀严格一致。
多态关联不是炫技用的，它解决的是“一个行为/资源要挂在多种模型上”这个真实痛点。用错场景反而增加复杂度，用对了能少建三张表、省掉一堆 if-else。
什么时候必须用 morphTo/morphMany
当同一个子模型（比如 Comment、Like、Attachment）需要被多个不相关的父模型复用时，就必须用多态。典型信号是：你开始想在数据库里加 post_id、video_id、product_id 这类并列外键，或者准备为每种父模型建一张独立的评论表。
- 评论系统：文章、视频、商品、直播页都能有评论 → 用
commentable_id+commentable_type - 点赞/收藏：用户点一次赞，可能针对文章、评论、甚至某条回复 →
likeable_id+likeable_type - 通用附件：图片、PDF、SVG 都挂到页面、产品、用户资料页 →
attachable_id+attachable_type - 操作日志：记录“谁修改了哪个配置项 / 哪个订单 / 哪个用户” →
loggable_id+loggable_type
反例：用户和收货地址是一对多，但地址只属于用户 —— 这里用普通 belongsTo 就够了，强行多态纯属给自己加字段。
morphTo 和 morphMany 的参数顺序别写反
morphTo() 写在子模型里（如 Comment），morphMany() 写在父模型里（如 Post）。关键陷阱是第二个参数：它必须和数据库字段前缀完全一致，且不能带下划线后缀。
- 如果数据库字段叫
commentable_id和commentable_type，那父模型里必须写$this->morphMany(Comment::class, 'commentable') - 写成
'comment'或'commentable_id'都会查不到数据 —— Laravel 会去拼comment_type或commentable_id_type这种不存在的字段 - 子模型里的
morphTo()可以不传参，Laravel 会自动推导为commentable；但显式写出来更安全：$this->morphTo('commentable')
联合唯一索引不是可选项，是防重复刚需
比如点赞，用户不能对同一篇文章点两次。靠应用层判断再删/插，高并发下照样会写入两条重复记录。必须靠数据库约束兜底。
- 迁移里加：
$table->unique(['user_id', 'likeable_type', 'likeable_id']); - 漏掉
likeable_type？那用户对文章 ID=1 和视频 ID=1 同时点赞，会被当成重复 —— 类型不同，ID 相同，不该冲突 - 没建索引？查某篇文章所有点赞时，
where likeable_type = ? and likeable_id = ?会全表扫描，数据一过万就明显变慢 - 别信
updateOrCreate()能处理多态：它内部用的是firstOrNew()，而多态字段无法被 Eloquent 的 where 条件正确识别，大概率查不到已存在记录
预加载 with() 时容易忽略的 N+1 问题
查 10 条评论并展示每条评论所属的文章标题，看似简单：Comment::with('commentable')->get()。但默认情况下，Laravel 会先查出所有评论，再为每个 commentable_type 单独发一条查询 —— 如果这 10 条评论分别属于 5 种模型，就会触发 5 次额外查询。
- 真正有效的预加载需要配合
MorphTo的懒加载优化，或手动分组查：先取所有唯一的commentable_type+commentable_id对，再按类型分批查父模型 - 开发阶段打开
DB::enableQueryLog()+dd(DB::getQueryLog())，一眼就能看出是不是在循环里查App\Models\Post、App\Models\Video…… - Debugbar 的 Queries 面板比代码里 dump 更直观，尤其能看出哪次查询来自
commentable关系
多态关联真正的复杂点不在定义，而在数据混合时的查询控制 —— 类型一多，with() 就容易失效，得靠手动分组或延迟加载来平衡性能和可读性。
