Lambda适用于单次使用、逻辑简单且无需复用的场景，如LINQ方法或事件回调；若逻辑复杂、需调试或可能复用，应优先使用命名方法。
什么时候该用 Lambda，而不是普通方法
当你只在某处用一次、逻辑不复杂、又不想额外定义一个命名方法时，Lambda 才真正省事。比如传给 Where、Select、OrderBy 这类 LINQ 方法，或者注册事件回调——这时候写个完整方法反而啰嗦。
但别为了“看起来高级”硬套：如果逻辑超过 3 行、需要调试、或可能被复用，老老实实写命名方法更稳妥。编译器对 Lambda 的调试支持不如普通方法直观，断点有时会跳到奇怪位置。
-
x => x.Name != null合适；x => { var tmp = x.Calc(); return tmp > 0 && tmp 就该拆出去 - 异步场景慎用
async/await在Lambda里——容易漏掉async声明，导致返回Task被当作void处理 - 捕获外部变量（闭包）时注意生命周期：
int i = 0; tasks.Add(Task.Run(() => Console.WriteLine(i))); i = 42;最终可能全输出42
=> 左右两边怎么写才不报错
左边是参数列表，右边是表达式或语句块。类型推导靠上下文，不是靠 Lambda 自身——所以它必须用在能明确目标委托类型的地方，比如方法参数是 Func<int, bool>，你写 x => x > 0 才能被识别为 int → bool。
常见报错：Cannot convert lambda expression to type 'xxx' because it is not a delegate type，基本就是上下文没提供委托类型信息。比如直接写 var f = x => x + 1; 就不行，因为 var 推不出委托类型。
- 单参数且无括号：
x => x.Length；多个或零参数必须加括号：(x, y) => x + y、() => DateTime.Now - 单表达式可省略
return和大括号；多语句必须加大括号和return：x => { Console.WriteLine(x); return x * 2; } - 返回类型必须匹配目标委托——
Func<string, int>不能写成s => s（返回string），得是s => s.Length
性能和内存上，Lambda 真的“轻量”吗
编译后，Lambda 会被转成静态方法或闭包类实例，不是运行时动态生成代码。所以“每次调用都新建函数对象”的担心是多余的——但闭包会带来额外开销。
无捕获的 Lambda（如 x => x * 2）会被编译器缓存为静态委托，只分配一次；一旦捕获外部变量（比如用了局部变量 i 或 this），就得生成一个闭包类，每次调用都可能 new 一次实例。
- 循环里写
list.Where(x => x.Id == id)没问题；但写for (int i = 0; i Console.WriteLine(i));就会创建 n 个闭包对象 - 在
foreach中捕获循环变量，C# 5+ 已修复，但早期版本有坑：foreach (var item in items) tasks.Add(Task.Run(() => Process(item)));现在安全，旧项目仍需留意 - 高频调用场景（如游戏帧更新、网络包解析），优先考虑预编译委托或命名方法，避免 GC 压力
调试 Lambda 时为什么断点不命中或跳错行
因为编译器把 Lambda 编译成独立方法（名字类似 <Main>b__0_0），源码映射有时不准，尤其带表达式树或异步时。VS 能显示，但堆栈里看不到原始 Lambda 位置。
最实用的调试方式：把 Lambda 临时替换成命名方法，加断点，确认逻辑正确后再换回——不是偷懒，是减少不确定性。
- 表达式树场景（如 EF Core 查询）：
Lambda会被转成Expression<Func<T, bool>>，此时根本不会执行 C# 代码，而是翻译成 SQL —— 断点完全无效 - 异步
Lambda：Task.Run(async () => await DoWork())必须声明async，否则编译器当同步处理，await不起作用，还可能吞异常 - Refactoring 工具（如 VS 的“提取方法”）对
Lambda支持有限，有时会把捕获变量漏掉或错改作用域
闭包生命周期、表达式树 vs 委托、异步声明缺失——这三个地方出问题，比语法错误更难一眼看出来。
