lambda 表达式是 c# 中委托和表达式树的底层构造，非语法糖；其正确性依赖类型推断、上下文匹配与闭包安全，误用会导致编译失败或运行时异常。
Lambda 表达式不是语法糖的装饰品，它是 C# 中委托和表达式树的底层构造方式。写错一个括号、漏掉一个类型、在错误上下文里用语句块，都会直接编译失败或运行时行为异常。
lambda 表达式的基本写法和参数省略规则
最简形式是 x => x * x，但这个“简”是有前提的：编译器必须能从目标委托签名中完整推断出 x 的类型和返回值类型。比如传给 Func<int int></int> 就行，传给 Action<object></object> 就会报错——因为右侧表达式返回 int，无法隐式转成 void。
- 单个参数且类型可推断时，括号可省：
w => w.Length - 多个参数或需显式声明类型时，括号和类型都不可省：
(string w, int i) => w.Length > i - 无参数必须写空括号：
() => DateTime.Now，不能写=> DateTime.Now - 语句块要用大括号，且必须有
return（除非目标是Action）：w => { Console.WriteLine(w); return w.Length; }
在 LINQ 中用 lambda 传参时为什么有时报错“无法转换为 Func”
常见于混用 IQueryable<t></t> 和 IEnumerable<t></t> 场景。比如 Entity Framework 查询中写了 list.AsQueryable().Where(x => x.Name.Contains("a"))，表面看没问题，但如果 list 是普通 List<t></t>，AsQueryable() 只是包装成内存查询，此时 lambda 被编译成委托；而真 EF 查询需要的是 Expression<func bool>></func>——它要被翻译成 SQL。两者类型不兼容，编译器会拒绝。
- 确认数据源类型：EF Core 查询用
DbSet<t></t>直接调用Where，才是表达式树路径 - 避免无意义的
AsQueryable()包装本地集合 - 调试时看 IntelliSense 提示的参数类型：如果是
Func<t bool></t>，说明走的是内存枚举；如果是Expression<func bool>></func>，才走表达式树
lambda 捕获外部变量引发的闭包陷阱
这是最容易被忽略的运行时问题。下面这段代码输出全是 5，而不是 0 到 4：
var actions = new List<action>(); for (int i = 0; i Console.WriteLine(i)); } foreach (var a in actions) a();</action>
原因：所有 lambda 共享同一个变量 i 的引用，循环结束时 i == 5。修复方式是在循环体内创建局部副本：
for (int i = 0; i Console.WriteLine(localI)); }
- C# 5+ 在
foreach中已修复该问题，但for循环仍需手动处理 - 捕获的变量生命周期会延长——只要 lambda 还活着，它引用的栈变量就不会被 GC 回收
- 在异步方法中捕获
this或大型对象，可能造成意外内存驻留
lambda 与方法组、匿名方法的取舍
不是越短越好。当逻辑超过 2–3 行、涉及异常处理、或需要复用时，lambda 反而降低可读性。
- 优先用方法组：如果已有现成方法
bool IsValid(string s)，直接写.Where(IsValid)比.Where(s => IsValid(s))更清晰 - 复杂逻辑拆成私有方法，别硬塞进 lambda：比如
.Select(x => ComputeScore(x) + Bonus(x))应该提取为GetTotalScore(x) - 匿名方法（
delegate { ... }）现在基本不用了，除非要省略参数列表又不想写() =>
真正难的不是怎么写 lambda，而是判断什么时候不该写——尤其在团队协作中，过度压缩的 lambda 会让后续维护者花三倍时间反推意图。
