EF查询使用构造函数初始化类时转换失败，但属性初始化则成功的原因

我完全懂你这种摸不着头脑的感觉——明明是同一个类，换个初始化方式EF就突然“罢工”了，这事儿确实挺让人挠头的。其实核心原因在于EF Core对两种初始化方式的查询转换逻辑差异：

一、构造函数初始化的转换限制 #

EF Core在把LINQ查询转成SQL时，对构造函数的要求相当严格：

• 要么使用无参构造函数，要么构造函数的参数必须和类的EF可追踪属性严格匹配（参数名、类型都得对应上），这样EF才能把构造函数调用映射到SQL的投影操作。
• 如果你的Foo类构造函数里包含了EF无法识别的逻辑（比如自定义计算、引用非EF实体类型），或者构造函数参数和你查询中投影的匿名类型字段不一一对应，EF就会因为没法解析这个转换过程，抛出“could not be translated”异常。
• 像你代码里先投影到匿名类型，再用它调用Foo构造函数的场景，EF很难追踪匿名类型到构造函数参数的映射关系，尤其是如果匿名类型里有Users这类复杂集合时，转换难度会更高。

二、属性初始化的兼容性优势 #

属性初始化（比如new Foo { Id = et.Id, Name = et.Name }这种写法）的逻辑对EF来说友好得多：

• 它本质是先调用类的无参构造函数（就算没有，EF也能通过反射创建实例），再逐个给属性赋值。这个过程EF可以分步解析：先把SQL查询的结果投影出来，再逐个映射到Foo的对应属性，逻辑简单直接。
• 就算有嵌套复杂类型或者集合属性，EF也能更好地处理这种逐属性赋值的逻辑，因为它不需要解析构造函数的参数匹配，只需要对应属性名即可。

举个和你代码对应的例子：

失败的构造函数写法：

.Select(et => new Foo(et.Id, et.Name, Users...))

成功的属性初始化写法：

.Select(et => new Foo { Id = et.Id, Name = et.Name, Users = ... })

前者EF需要验证构造函数参数和投影字段的匹配度，还要确保构造函数逻辑可转换；后者只需要把投影字段赋值给对应属性，自然更容易通过转换。

备注：内容来源于stack exchange，提问作者gilliduck