多态关联需严格匹配字段类型、显式声明关系并手动处理软删除——类型不匹配导致静默空结果，反向关系缺失使预加载失效，跨模型查询易出错，软删除需显式透传。
多态关联不是“自动适配”，而是靠字段约定和显式声明驱动的——写错一个外键名或类型，查询就静默返回空数组。
polymorphic foreign key 字段类型必须和目标主键一致
最常见的静默失败：给 commentable_id 设成 unsignedInteger，但被关联的 Post 或 Video 主键是 bigIncrements（即 BIGINT）。数据库层面类型不匹配，JOIN 失败，Eloquent 不报错，只返回空集合。
- 检查所有被关联模型的主键类型：
php artisan tinker中运行(new Post)->getKeyName()和(new Post)->getKeyType() - 迁移中统一用
$table->morphs('commentable')——它会自动生成commentable_id（unsignedBigInteger）和commentable_type（string） - 手动建字段时，别抄
integer示例，务必匹配实际主键类型；bigIncrements对应unsignedBigInteger，不是unsignedInteger
with() 预加载多态关系时必须显式指定关系名
写 Comment::with('commentable') 看似合理，但 Eloquent 无法自动推断该调用哪个模型的关联方法。它只会查 commentable_id 和 commentable_type，然后对每个类型单独发起查询——但如果没在对应模型里定义同名关系（比如 Post::commentable()），就什么也加载不出来，且不报错。
- 确保每个可被关联的模型都定义了同名的反向多态关系：
Post里要有public function commentable() { return $this->morphOne(Comment::class, 'commentable'); } - 预加载时不能只靠字段名，必须确认关系方法存在且返回正确构造器
- 调试技巧：临时在
Comment模型的commentable()方法里加dd($this->morphTo());，看是否能正确解析出目标模型
whereHas() 和 whereDoesntHave() 在多态场景下容易漏数据
执行 Post::whereHas('comments') 是安全的，但若换成 Comment::whereHas('commentable', function ($q) { $q->where('title', 'like', '%bug%'); })，就会出问题：Eloquent 生成的 SQL 默认用 IN 子查询 + UNION 合并多个模型的条件，一旦某个模型没实现该字段（比如 Video 表没有 title），整条查询可能直接报错或跳过该类型。
- 避免跨模型字段筛选；如需搜索，改用原生
join显式指定表别名和字段 - 更稳妥的做法是分两次查：
Post::where('title', 'like', '%bug%')->pluck('id')+Video::where('title', 'like', '%bug%')->pluck('id')，再用whereIn('commentable_id', [...])和whereIn('commentable_type', [...]) - 注意
whereDoesntHave()的语义是“完全不满足”，不是“某类不满足”，多态下逻辑更难直观验证
软删除模型参与多态关联时，withTrashed() 必须手动透传
如果 Post 启用了软删除，而你调用 Comment::with('commentable')，默认不会加载已软删除的 Post。Eloquent 不会自动识别反向关系是否需要包含软删除数据。
- 要在预加载时包含软删除记录，必须显式链式调用：
Comment::with(['commentable' => function ($q) { $q->withTrashed(); }])->get() - 同样适用于
withoutTrashed()场景：当Comment自身软删除，但你想查其关联的活跃Post，得在commentable()关系定义里加->withoutTrashed() - 这个行为不会继承，每次涉及软删除的多态查询，都要重新声明
多态关联真正的复杂点不在语法，而在它的“动态性”——Eloquent 不会在构建查询前校验所有可能的目标模型是否存在、字段是否兼容、软删除状态是否一致。它信任你写的每一个字符串和类型声明，然后默默执行，直到结果不符合预期才暴露问题。
