为什么EF Core的LINQ Join用自定义类作键选择器会报无法翻译错误？

Entity Framework Core 3.1 的查询翻译管线对 Join 操作的键选择器存在严格的特化匹配规则，核心逻辑是只对预先定义的几类带值相等语义的类型，执行“拆分属性为数据库端等值匹配条件”的翻译逻辑，其余类型的返回值都会被识别为需要在内存中构造CLR对象的不可翻译操作。

• 匿名类型可以正常运行的原因：
  C# 编译器生成的匿名类型天生是值相等语义——编译器会自动重写类型的Equals/GetHashCode方法，实现所有属性的逐值比较。EF Core 从早期版本就针对匿名类型做了专门的硬编码翻译适配：检测到键选择器返回匿名类型时，会直接遍历类型的所有属性，把每个属性映射为对应的数据库列等值匹配条件，跳过对“整个对象实例相等”的翻译尝试，最终生成正确的多表Join SQL。
• 自定义KeyClass报错的原因：
  普通自定义类是引用相等语义，默认的Equals判断只比较对象的内存引用，不会逐属性比较值。EF Core 3.1 的翻译器在碰到返回自定义命名类的键选择器时，会把new KeyClass { Key = x.ID }识别为需要在本地内存构造对象的操作——它不会自动像处理匿名类型那样拆解类属性生成数据库匹配条件。这类普通自定义类的属性可能是计算属性、存在外部依赖，EF Core 3.1 无法保证拆解后的表达式都能对应到数据库列，因此不会主动做属性拆分的尝试。这类涉及本地对象构造的操作不符合EF Core 3.1“查询逻辑尽可能下推到数据库执行”的核心设计，因此会直接抛出LINQ表达式无法翻译的错误。
• 版本特性说明：
  EF Core 3.1 仅特化支持两类类型作为Join键的翻译：编译器生成的匿名类型、ValueTuple值元组。直到EF Core 5.0版本才逐步放开对带值相等语义的自定义类、record类型的翻译支持，3.1 版本没有加入这类适配逻辑，因此哪怕你手动给自定义类实现了值相等的方法，也无法被正确翻译。

你因为运行时动态生成Join逻辑需要使用Emit创建的键类型，可以参考以下方案避开3.1的翻译限制：

• 优先使用ValueTuple替代自定义Emit类型：EF Core 3.1 完整支持值元组作为Join键的翻译，你可以根据运行时的键配置，动态拼接返回不同列数的元组表达式（比如两列键返回(x.ID, x.Code)、三列键返回(x.ID, x.Code, x.Type)），翻译效果和匿名类型完全一致，不需要额外做类型生成逻辑。
• 如果必须使用Emit生成动态键类型，生成的类型必须完全模拟C#匿名类型的实现特征：所有属性为公共只读、自动重写Equals/GetHashCode实现逐属性值相等、无额外的业务逻辑或状态字段，只有完全匹配匿名类型的结构特征，才有可能被EF Core 3.1的翻译器识别为可翻译的键类型。

内容的提问来源于stack exchange，提问作者qscott86