.NET Core 3.1.8下EF Core在.Where中使用.Contains触发查询翻译失败问题

这不是EF Core的运行异常，完全是代码实现的疏漏，核心问题是编写的查询表达式无法被翻译为数据库可执行的SQL语句。

异常产生的逻辑链路 #

• 你当前的查询中，本地变量bookIds是拆分后的字符串数组，为了实现和数据库字段的匹配，你对数据库侧的b.SttmId（可空长整型，类型为long?）调用了ToString()方法。
• EF Core的SQL翻译引擎无法识别“数据库端长整型转字符串”这个操作：数据库不存在和C#完全等价的类型转换规则（涉及空值处理、格式对齐等逻辑差异），因此整个表达式无法完成翻译，最终抛出指定的“无法翻译LINQ表达式”异常。
• 你提到的可正常运行的单值等值查询，本质是直接在数据库侧对同类型的长整型字段做比较，这个操作可以直接翻译成WHERE SttmId = @bookId的标准SQL，因此能正常执行。

推荐的正确实现方式 #

最合理的写法是完全避免在数据库侧做类型转换，在客户端就把本地的字符串集合处理为和SttmId同类型的长整型集合：

// 拆分字符串时自动过滤空值、去除元素前后的多余空格，转换为可空长整型集合
var bookIds = source.Sids.Split(",", StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries)
                         .Select(id => long.TryParse(id, out var parsedId) ? parsedId : default(long?))
                         .ToList();

var hkm = _context.Books
                  .Include(b => b.Writer)
                  // 同类型集合直接做Contains匹配，EF会自动翻译成标准的IN子句
                  .Where(b => bookIds.Contains(b.SttmId))
                  .ToList();

• 这种写法没有任何数据库侧的自定义类型转换，生成的SQL和常规多值等值查询完全一致，执行性能最优，也不会触发翻译异常。

不推荐的临时兜底方案 #

如果不调整类型转换逻辑，可以通过AsEnumerable()强制切换为客户端求值模式，但这种写法会把整个Books表（以及关联加载的Writer表）的全部数据拉取到本地内存后再做过滤，数据量较大时会产生严重的性能问题，代码示例：

// 仅适合数据量极小的场景，非必要不要使用
var hkm = _context.Books
                  .Include(b => b.Writer)
                  .AsEnumerable()
                  .Where(b => bookIds.Contains(b.SttmId?.ToString()))
                  .ToList();

现有代码的额外疏漏 #

• 原代码的字符串拆分未配置处理选项，遇到连续逗号、元素前后带空格的场景，拆分结果会包含无效值，哪怕核心逻辑修正后，也可能出现匹配失败的问题。
• 原代码写的是小写的toString()，C#中长整型转字符串的标准方法是Pascal命名的ToString()，写法本身不符合C#的通用规范，存在潜在的语法兼容隐患。

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