EF Core 查询分表依赖对象，却混入其他 TPH 类型的行

Animal 使用 TPH 继承，Cat 和 Dog 都在同一张表里；CatProfile 通过一对一关系与 Cat 共享这张表。此时直接执行 context.Set<CatProfile>()，结果里却出现 Dog 对应的行，甚至被组装成一个本来不存在的 CatProfile。

先查看生成 SQL。若它只读取共享表的 Id、Note 等列，却没有限制 Cat 的 Discriminator，问题在结果范围，而不只是导航属性没加载。

共享一张表，不代表每一行都有该依赖对象

这个场景要求依赖对象属于某个派生类型，并与主体共享表和键。Cat 的必需导航，只能说明 Cat 行需要 CatProfile，不能推出 Dog 行也具有同一个对象。

若从 Cat 的导航加载 Profile 得到正确范围，直接查询 CatProfile 却混入其他鉴别值，可进一步核对这条查询路径。EF Core 7、8、9、10 的所述模型均有这一现象，但不能据此把所有继承查询或表拆分故障都视为同一问题。先核对实际关系、表名、主外键和鉴别列值，再比较两条查询生成的 SQL。

从正确的派生主体进入查询

若业务读取的就是 Cat 的 Profile，可以先限定主体，再投影导航。以下示例假定 Cat、Profile 的模型配置已经存在：

var profiles = await context.Set<Animal>()
    .OfType<Cat>()
    .Select(cat => cat.Profile)
    .AsNoTracking()
    .ToListAsync();

也可以从 context.Set<Cat>() 开始。关键是最终 SQL 明确把主体限制为 Cat，并保持原来的关联条件。先用只读查询比较实际 SQL、返回 Id 和已知数据，再替换应用入口；不要仅看返回数量变少就认为修复完成。

原查询若有租户、软删除、授权范围、排序或分页，需要逐项迁移。过滤器定义在哪个实体上，会影响导航投影后的结果，不能默认直接查询依赖对象与查询主体天然等价。还应保留业务原有的 DTO 投影，避免为了这个问题顺便改变接口结构。

用不同类型的真实边界验证

准备分别属于 Cat 和 Dog 的受控数据，确认 CatProfile 查询只返回 Cat 对应的键。再覆盖空结果、多个 Cat、依赖字段允许 NULL 的情况，并核对加载导航的结果与替代查询一致。

不要用 Note != null 一类业务字段代替鉴别列判断。合法的 CatProfile 可能允许该字段为空，其他类型的同列也可能有值；这会把当前错误换成另一种数据筛选错误。更不能因为结果里出现了 Dog，就删除那些共享表行。

若应用必须独立暴露依赖类型查询，长期方案需要重新评估查询映射或模型结构，并独立处理迁移和兼容性。当前入口调整不要求改表。升级后重新比较直接依赖查询与派生主体投影的 SQL 和结果，再决定是否恢复原入口。