LINQ按子实体属性分组计算子实体属性总和时报错的原因与解决方法

核心报错原因拆解 #

• Include在分组查询中失效的认知误区：你写的Include(p => p.Child)在带服务器端分组的查询里本身就不会生效——EF Core的Include规则是针对连续实体查询的，一旦做了GroupBy聚合，查询结果不再是完整的Parent实体集合，Include的导航属性加载逻辑会被完全忽略，相当于你在实际的SQL执行链路里根本没有声明和Child表的关联路径，自然没法访问Child表的字段。
• 跨表导航属性的SQL翻译歧义：EF Core对服务器端执行的分组聚合查询，仅支持对当前查询链路中已明确声明的标量属性做聚合计算。你在求和逻辑中访问的p.Child.Amount属于跨表的嵌套导航属性，和之前分组键里的p.Child.Type并没有建立明确的关联映射，翻译器无法判断你要聚合的是哪个路径下的Child.Amount字段，会直接抛出“查询无法翻译为可执行SQL”的运行时错误。
• 一对多关系下的导航类型不匹配：常规业务中Parent与Child是一对多关系，此时Parent实体的Child属性是ICollection<Child>类型的集合导航，并非单个Child对象。在聚合函数中直接对集合类型访问.Amount属性，本身就存在类型不匹配的问题，哪怕脱离EF环境、在内存中执行LINQ to Objects查询，这行代码都无法通过编译。
• 替换为父实体属性就能正常运行的逻辑很直白：p.Amount是Parent实体自身的标量属性，和当前查询的主表直接对应，不存在跨表导航的解析歧义，也没有集合类型的访问问题，翻译器可以顺利生成对应的分组聚合SQL，自然不会触发报错。

匹配需求的正确查询写法 #

需求本质是按Child的Type维度分组，统计对应Child实体的Amount总和，完全没必要硬嵌套在Parent实体的查询里做跨表访问，两种高效写法如下：

• 直接以Child实体为查询入口，逻辑最直接，SQL翻译效率最高：
  context.Child.GroupBy(c => c.Type).Select(g => g.Sum(c => c.Amount)).ToList()
• 如果业务逻辑必须从Parent实体发起查询，需要先通过SelectMany展开所有关联的Child集合，拉平数据后再做分组聚合：
  context.Parent.SelectMany(p => p.Child).GroupBy(c => c.Type).Select(g => g.Sum(c => c.Amount)).ToList()

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