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

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

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

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

主要原因是当您不想直接运行代码，而是想检查它时。这可能有很多原因:

Mapping the code to a different environment (ie. C# code to SQL in Entity Framework) Replacing parts of the code in runtime (dynamic programming or even plain DRY techniques) Code validation (very useful when emulating scripting or when doing analysis) Serialization - expressions can be serialized rather easily and safely, delegates can't Strongly-typed safety on things that aren't inherently strongly-typed, and exploiting compiler checks even though you're doing dynamic calls in runtime (ASP.NET MVC 5 with Razor is a nice example)

当使用LINQ-to-SQL时，将Func<>s传递给Where()或Count()是不好的。真正的坏。如果你使用Func<>，那么它调用IEnumerable LINQ的东西，而不是IQueryable，这意味着整个表被拉进来，然后过滤。表达式<Func<>>明显更快，因为它在SQL服务器上执行过滤-特别是如果您正在查询位于另一个服务器上的数据库。

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

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

我想补充一些关于Func<T>和Expression<Func<T>>的区别:

Func<T> is just a normal old-school MulticastDelegate; Expression<Func<T>> is a representation of lambda expression in form of expression tree; expression tree can be constructed through lambda expression syntax or through the API syntax; expression tree can be compiled to a delegate Func<T>; the inverse conversion is theoretically possible, but it's a kind of decompiling, there is no builtin functionality for that as it's not a straightforward process; expression tree can be observed/translated/modified through the ExpressionVisitor; the extension methods for IEnumerable operate with Func<T>; the extension methods for IQueryable operate with Expression<Func<T>>.

有一篇文章用代码示例描述了细节: LINQ: Func<T> vs. Expression<Func<T>>。

希望对大家有所帮助。

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