Lambda 表达式在 C# 中不是语法糖，而是编译器生成委托或表达式树的正式机制——它既可运行（Func<t r></t>
），也可被“看”（Expression<func r>></func>
），这点决定了你用错场景时会直接报错或查不到数据。
什么时候该用 Func
，什么时候必须用 Expression<func></func>
核心区别不在写法，而在「执行时机」和「目标 API 要求」：
如果调用的是IEnumerable<t>.Where()</t>（如内存 List）、
Task.Run()、事件注册，用
x => x.Age > 18就是
Func<person bool></person>，直接执行，快且无限制 如果调用的是
IQueryable<t>.Where()</t>（如 Entity Framework、LINQ to SQL），API 实际接收的是
Expression<func bool>></func>—— 它不执行，而是把 lambda “翻译成 SQL”。此时若你传入一个已编译的委托（比如先赋值给
Func变量再传），会抛出
InvalidOperationException: The LINQ expression could not be translated显式声明类型可避免歧义：
Expression<Func<Person, bool>> expr = p => p.Name.StartsWith("A"); // ✅ 可被 EF 翻译<br>Func<Person, bool> func = p => p.Name.StartsWith("A"); // ❌ 传给 IQueryable.Where 会失败
=>
左右两边的类型推断规则和常见翻车点
编译器能推类型，但只在上下文明确时才可靠；一旦模糊，就报错或行为异常：
单参数可省括号：x => x.Length合法；但
x, y => x + y❌ 必须写成
(x, y) => x + y参数类型不能靠“猜”：当没有目标委托类型（比如单独写
var f = x => x * 2;），C# 10+ 支持隐式泛型推导，但若用于方法重载，可能选错重载项 返回类型必须严格匹配：写
(int x) => x.ToString()给
Func<int string></int>没问题，但给
Func<int object></int>会失败（C# 不自动协变返回类型） 空参数必须写
()：
() => "hello"✅，
=> "hello"❌ 编译错误
闭包捕获变量的真实生命周期和陷阱
Lambda 捕获的是「变量本身」，不是「值快照」——这导致循环中常出现所有委托都引用最后一个值的问题：
典型错误：var handlers = new List<Action>();<br>for (int i = 0; i < 3; i++) {<br> handlers.Add(() => Console.WriteLine(i)); // 全部输出 3<br>}
修复方式：在循环内创建局部副本：for (int i = 0; i < 3; i++) {<br> int localI = i;<br> handlers.Add(() => Console.WriteLine(localI)); // 输出 0, 1, 2<br>}
注意：捕获的变量只要还有委托引用它，就不会被 GC 回收。长期存活的委托（如静态事件处理器）意外捕获大对象，会造成内存泄漏
语句块 Lambda 的 return 和 void 返回必须显式处理
表达式形式（
x => x * 2）自动返回；但语句块（
{ ... }）必须手动 return，否则编译失败： 正确：
Func<int, int> f = x => {<br> if (x < 0) return 0;<br> return x * x;<br>};
错误：Func<int, int> f = x => {<br> Console.WriteLine(x); // ❌ 缺少 return，编译报错 CS0161</br>};
如果是 Action（无返回值），语句块里就不能写
return 表达式，只能写
return;或不写
真正容易被忽略的，是表达式树和委托在底层根本不是同一个东西——EF 报错时不会告诉你“你用了委托而不是表达式”，只会说“无法翻译”。遇到查询失败，第一反应不该是改逻辑，而应检查变量类型声明是否强制为
Expression。
