在选择表达式和Func时，一个非常重要的考虑因素是IQueryable提供者，如LINQ to Entities可以“消化”你在表达式中传递的内容，但会忽略你在Func中传递的内容。关于这个主题，我有两篇博文:

更多关于表达式vs函数与实体框架和 爱上LINQ -第7部分:表达式和功能函数(最后一部分)

我添加了一个针对新手的答案，因为这些答案似乎超出了我的理解范围，直到我意识到它是多么简单。有时是你认为事情很复杂，这让你无法“理清思路”。

我不需要理解其中的区别，直到我遇到了一个非常烦人的“bug”，试图一般地使用LINQ-to-SQL:

public IEnumerable<T> Get(Func<T, bool> conditionLambda){
  using(var db = new DbContext()){
    return db.Set<T>.Where(conditionLambda);
  }
}

这工作得很好，直到我开始在更大的数据集上得到outofmemoryexception。在lambda中设置断点使我意识到它正在逐一遍历表中的每一行，寻找与lambda条件匹配的条件。这让我困惑了一段时间，因为为什么它把我的数据表作为一个巨大的IEnumerable，而不是像它应该做的那样做LINQ-to-SQL ?它也在我的LINQ-to-MongoDb对应版本中做同样的事情。

修复方法是简单地将Func<T, bool>转换为表达式<Func<T, bool>>，所以我谷歌了为什么它需要一个表达式而不是Func，在这里结束。

表达式只是将委托转换为关于自身的数据。所以a => a + 1就变成了"左边有一个整数a，右边你给它加1 "就是这样。你现在可以回家了。它显然比这更有结构，但这本质上就是表达式树的全部——没有什么可以让你理解的。

Understanding that, it becomes clear why LINQ-to-SQL needs an Expression, and a Func isn't adequate. Func doesn't carry with it a way to get into itself, to see the nitty-gritty of how to translate it into a SQL/MongoDb/other query. You can't see whether it's doing addition or multiplication or subtraction. All you can do is run it. Expression, on the other hand, allows you to look inside the delegate and see everything it wants to do. This empowers you to translate the delegate into whatever you want, like a SQL query. Func didn't work because my DbContext was blind to the contents of the lambda expression. Because of this, it couldn't turn the lambda expression into SQL; however, it did the next best thing and iterated that conditional through each row in my table.

编辑:应约翰·彼得的要求，对我的最后一句话进行解释:

IQueryable extends IEnumerable, so IEnumerable's methods like Where() obtain overloads that accept Expression. When you pass an Expression to that, you keep an IQueryable as a result, but when you pass a Func, you're falling back on the base IEnumerable and you'll get an IEnumerable as a result. In other words, without noticing you've turned your dataset into a list to be iterated as opposed to something to query. It's hard to notice a difference until you really look under the hood at the signatures.

在选择表达式和Func时，一个非常重要的考虑因素是IQueryable提供者，如LINQ to Entities可以“消化”你在表达式中传递的内容，但会忽略你在Func中传递的内容。关于这个主题，我有两篇博文:

更多关于表达式vs函数与实体框架和 爱上LINQ -第7部分:表达式和功能函数(最后一部分)

这里过于简化了，但Func是一个机器，而Expression是一个蓝图。: D

这是我的两分钱…

Func<T> =一个刚被执行的委托/方法，仅此而已。 表达式<Func<T>> =转换为另一种形式。例如，LINQ to Entities表达式被转换为等效的SQL查询。

想象一下，两者看起来很相似，但表达式就像一个数据结构，具有反射的能力。编译器实际上知道关于它的签名和主体的所有信息(类似于类反射)。利用这些知识，表达式被转换为其他形式，就像LINQ被转换为SQL查询一样。

现在，还有另一个角度来处理IQueryable行为。建议您始终传递LINQ的Expression to Where或Count方法，以便您的查询过滤器在SQL server上运行，而不是在内存中提取数据然后进行过滤。

LINQ是典型的例子(例如，与数据库对话)，但事实上，任何时候您更关心表达要做什么，而不是实际做什么。例如，我在protobuf-net的RPC堆栈中使用这种方法(以避免代码生成等)-所以你调用一个方法:

string result = client.Invoke(svc => svc.SomeMethod(arg1, arg2, ...));

这将分解表达式树以解析SomeMethod(以及每个参数的值)，执行RPC调用，更新任何ref/out参数，并从远程调用返回结果。这只能通过表达式树实现。我在这里讲得更多。

另一个例子是为了编译为lambda而手动构建表达式树，就像使用泛型操作符代码一样。