在C#后端开发中，使用Entity Framework Core访问数据库时，模糊查询是最常用的功能之一。很多场景下我们需要根据用户输入的关键字去匹配字段中的部分内容，这时候通常会接触到两种写法：使用EF.Functions.Like方法，以及使用LINQ里的Contains方法。虽然它们都能实现“找包含某些字符的记录”，但在底层SQL生成、索引利用和代码可读性上存在明显区别。
一、Contains方法的基本用法与原理
Contains是LINQ to Objects和LINQ to Entities都支持的方法，在EF Core中，当你在IQueryable上调用string.Contains时，提供程序会尝试将其翻译成对应的SQL语句。在大部分主流关系型数据库（如SQL Server）中，EF Core会把Contains翻译为使用LIKE '%关键词%'或者CHARINDEX函数的查询条件。
下面是一段典型的Contains用法示例，假设我们有一个Product实体，需要根据名称搜索：
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
}
// 在DbContext的派生类中或仓储里使用
public List<Product> SearchByName(string keyword)
{
using var context = new MyDbContext();
// 在IQueryable上调用Contains，会被翻译到数据库端执行
var query = context.Products
.Where(p => p.Name.Contains(keyword));
return query.ToList();
}
这种写法非常直观，不需要记忆通配符，适合“只要字段里出现过这个子串就返回”的简单需求。不过要注意，如果keyword为null或者空字符串，Contains的行为需要额外处理，否则可能匹配全部或抛出异常。
从性能角度看，Contains生成的'%关键词%'形式通常无法有效利用B树索引的前缀匹配特性，在大数据表中可能导致全表扫描。但它胜在语义清晰，且EF Core能保证参数化，避免SQL注入。
二、EF.Functions.Like的灵活用法
EF.Functions.Like是EF Core提供的数据库函数映射，它允许开发者显式写出类似原生SQL的LIKE模式，通过百分号（%）、下划线（_）等通配符控制匹配位置。这种方式比Contains更灵活，例如你可以只查以某字符串开头、以某字符串结尾，或者特定位置字符匹配的记录。
示例代码如下，展示了前缀匹配、后缀匹配和中间匹配三种常见情况：
public List<Product> SearchWithLike(string keyword)
{
using var context = new MyDbContext();
// 前缀匹配：名字以keyword开头
var startWith = context.Products
.Where(p => EF.Functions.Like(p.Name, keyword + "%"))
.ToList();
// 后缀匹配：名字以keyword结尾
var endWith = context.Products
.Where(p => EF.Functions.Like(p.Name, "%" + keyword))
.ToList();
// 中间包含：等同于Contains，但可显式控制
var middle = context.Products
.Where(p => EF.Functions.Like(p.Name, "%" + keyword + "%"))
.ToList();
return middle;
}
使用Like的最大优势是可精确控制通配符位置。例如前缀匹配在Name字段有索引时，数据库优化器有可能使用索引范围扫描，性能优于无前缀限制的Contains。此外，当你需要匹配单个字符（如下划线）或转义特殊字符时，Like也更直接。
不过，Like要求开发者自己拼接字符串，容易因忘记加百分号而写成完全匹配，且手拼时若未使用参数化（直接内联字符串）会有注入风险。好在上面的写法中keyword仍是参数，EF Core会处理为参数化查询。
三、二者对比与客户端求值陷阱
为了更清楚地看到差异，我们可以从翻译结果、可读性和适用场景三个维度对比：
| 对比项 | Contains | EF.Functions.Like |
|---|---|---|
| SQL翻译 | LIKE '%x%' 或 CHARINDEX | 显式 LIKE 模式 |
| 通配符控制 | 仅中间包含 | 前后缀、单字符均可 |
| 代码直观性 | 高，无需通配符知识 | 中，需写模式串 |
| 索引友好度 | 通常全表扫描 | 前缀匹配可利用索引 |
除了上面这些区别，还有一个容易被忽略的坑：客户端求值。如果你在代码中先使用了AsEnumerable或ToList，把数据拉到内存后再调用Contains，那么模糊查询就不在数据库端执行，而是遍历内存对象。对于大表，这会严重拖慢性能并消耗内存。
错误示例如下，应当避免：
// 错误：先ToList再Contains，全表加载到内存
var list = context.Products.ToList();
var bad = list.Where(p => p.Name.Contains(keyword)).ToList();
// 正确：在IQueryable上直接查询
var good = context.Products
.Where(p => EF.Functions.Like(p.Name, "%" + keyword + "%"))
.ToList();
因此，无论使用Like还是Contains，都要保证查询方法链停留在IQueryable上，直到最后才执行枚举操作。这样EF Core才能把条件翻译成SQL，在数据库内完成过滤。
四、实践中的选择建议
如果你的需求仅仅是“字段包含某关键词”，并且不关心索引细节，用Contains可以让代码更简洁，也降低通配符拼写出错的概率。它在团队维护性和可读性上表现更好，适合后台管理系统的通用搜索框。
当你需要更精细的匹配逻辑，比如用户输入了“开头是A且结尾是B”的规则，或者希望通过前缀匹配来借助数据库索引提升速度，就应该选择EF.Functions.Like。在一些报表或高频接口中，合理使用前缀Like能明显减少查询耗时。
另外，对于用户输入的特殊字符（如%、_本身），若使用Like需要借助ESCAPE子句转义，而Contains一般交由参数化处理，不需要额外逻辑。实际项目中可以封装一个扩展方法，根据入参自动选择Like或Contains，并统一处理空值和转义，既兼顾性能也保留简洁性。
C#_EF_CoreLikeContains修改时间：2026-08-05 23:09:31