很多人在 C# 里一看到=>就条件反射地认为是 Lambda 表达式。这个印象不能算全错，但至少不够准确。=>在 C# 里其实还有另外两类高频用法，而且它们在日常业务代码里出现的频率一点也不比 Lambda 低。有不少人写了好几年 C#，一直把下面这种写法当成 Lambda：

public string Name => _name;

第一眼看上去很像 Lambda，编译器也用了同一个箭头符号，但它的真实身份是“表达式体成员”。Lambda 是创建委托或表达式树，而表达式体成员是精简成员实现。两者在编译器眼里的处理路径完全不同。这篇文章就把=>在 Lambda 之外的两类核心用法拆开讲清楚，顺带解决几个我在实际项目里见过的高频误用场景。

1. 先搞懂=>的本质：同一个符号，三种不同的编译意图

1.1 箭头符号在 C# 里的三个身份

=>在 C# 里一共出现在三种上下文里。第一种是大多数人熟悉的 Lambda 表达式：

Func<int, int> square = x => x * x;

右侧x * x会被编译器转换成一个委托方法，或者一棵表达式树。这是=>最原始的用途，很多资料把它当作唯一的用途来讲，于是把后面两种埋没了。

第二种是表达式体成员。它从 C# 6 开始引入，最初支持方法、属性和索引器，后来在 C# 7 里扩展到构造函数、析构函数和属性访问器。写法长这样：

public int Double(int value) => value * 2;

这句代码等价于：

public int Double(int value) { return value * 2; }

编译器在编译时会把箭头右侧的表达式包装成方法的 return 语句。注意这里的=>不是创建委托，而是告诉编译器“整个方法体就是这一个表达式”。这是理解全文的关键分界线：Lambda 的箭头是生成一个匿名函数对象，表达式体成员的箭头是生成一个完整成员的方法体。

第三种看起来不太像，但同样是=>参与构造的语法。C# 7 之后，构造函数、析构函数、属性 get/set 访问器也支持表达式体写法。比如构造函数：

public Person(string name) => Name = name;

再比如 set 访问器：

public string Name { get => _name; set => _name = value; }

严格来说，第三种是第二种的扩展，本质上同属于“表达式体成员”这个大范畴，但应用场景和编译器展开逻辑差异很大。为了符合大多数人的认知习惯，下文把“表达式体成员基础用法”和“构造函数/访问器高级用法”当作独立的两种用法来讲。理解了这三个身份，你再看任何=>代码都不会懵。

1.2 编译器怎么区分这三者

很多人好奇一个问题：同样是=>，编译器是靠什么判断它到底是 Lambda 还是表达式体成员的？其实答案非常直白——靠所在位置的语法上下文。

• 如果=>出现在一个方法调用的参数里、变量赋值的右侧、或者返回值的位置，并且左侧是一个参数列表，那就是 Lambda。
• 如果=>出现在类成员声明的位置，左侧是成员签名（属性名、方法名、构造函数名），那就是表达式体成员。

举个直观的例子：

// 这是 Lambda var action = (int x) => x * 2; // 这是表达式体方法 int Multiply(int x) => x * 2;

两行代码长得非常像，但编译器第一行生成一个Action<int>委托，第二行直接生成一个名为Multiply的私有方法。也就是说，=>本身没有固定的语义，它在哪出现就遵循哪套规则。这个特性让一些新手在看代码时感到迷惑，但也让 C# 在表达“单表达式实现”这个场景时异常简洁。

从这个角度再深入一层，表达式体成员的引入动机其实很简单：C# 里有大量成员的方法体只有一个 return 表达式，比如只读属性、简单的 ToString 重写、类型转换运算符。为了一个表达式写一对大括号加 return，代码显得非常啰嗦。C# 团队在语言演进过程中把这个高频模式收编成了语法糖，这就是表达式体成员诞生的背景。

2. 第一种用法：表达式体成员，C# 6 带来的属性与方法简写

2.1 只读属性与计算属性的单行化

先看最常用的场景：只读属性。业务代码里最常见的 DTO 和领域对象里，有大量只读属性是从其他字段或属性计算得来的。用传统写法：

private readonly List<string> _items = new List<string>(); public int Count { get { return _items.Count; } }

这段代码从语义上只有一件事——把_items.Count暴露出去。用表达式体成员写：

public int Count => _items.Count;

效果完全一样。编译器生成的 IL 里依然是一个get_Count方法，方法体只有一条 return 指令。很多人把这个=>误认成 Lambda，其实它根本不是。它只是把{ get { return ...; } }缩写成=> ...;。

计算属性的场景更典型。比如定义一个根据出生日期计算年龄的属性：

public int Age => DateTime.Now.Year - BirthDate.Year;

这种只有一个表达式、不需要中间变量的逻辑，是表达式体成员的最佳使用场景。它减少的不仅是代码量，还有阅读时的视觉噪音。原来读一个五行的属性要在大括号之间找 return，现在一行就能看到完整的计算逻辑。

用这个写法时有一个细节值得注意：这个写法只适用于只读属性。如果属性需要同时提供 get 和 set，就不能用单一的=>完成整个属性，需要在 get 和 set 上分别写表达式体。这点在文章第三部分访问器用法里会展开。

2.2 方法与运算符重载的简化

除了属性，普通方法的表达式体也非常常见。典型场景是重写 ToString：

public override string ToString() => $"{Name} ({Age} 岁)";

等价写法是：

public override string ToString() { return $"{Name} ({Age} 岁)"; }

另一个高频点是比较方法的简写。比如定义排序器：

public int CompareTo(Person other) => Age.CompareTo(other.Age);

再比如运算符重载：

public static Person operator +(Person a, Person b) => new Person(a.Name + " & " + b.Name, a.Age + b.Age);

这里要特别注意一个容易被忽略的细节：表达式体方法也支持 void 方法。很多人以为只有返回值的方法才能用=>，其实不是。C# 6 开始，void 方法也能用表达式体，只是此时箭头右侧是一个语句表达式而不是返回表达式。看这个例子：

public void Print() => Console.WriteLine(Name);

编译器会把右侧的Console.WriteLine(Name)解释为方法体的调用语句，而不是return Console.WriteLine(Name)。这一点和 Lambda 的行为有本质区别。Lambda 代码块里如果写x => Console.WriteLine(x)，编译器是把这句当作表达式语句，不会尝试把它当作返回结果；表达式体方法也遵循这个逻辑。所以写 void 方法简写时放心用，不需要在箭头右侧写return。

2.3 索引器与运算符重载的表达式体写法

索引器也是表达式体成员支持的类型。常见写法：

public string this[int index] => _items[index];

这等价于：

public string this[int index] { get { return _items[index]; } }

索引器的表达式体写法在集合封装类里非常实用。我之前在某项目的分页结果类里见过这么一段：

public T this[int index] => Items[index];

一行暴露只读索引，避免了为集合类单独写几十行样板代码。运算符重载的表达式体写法适合简单二元运算，比如向量加法、金额累加。这类逻辑往往就一行表达式，用=>会特别自然。

3. 第二种用法：C# 7 扩展的构造函数、析构函数与访问器

3.1 构造函数表达式体：一行完成字段初始化

C# 7 把表达式体成员扩展到了构造函数、析构函数以及属性的 get/set 访问器上。构造函数最常见的表达式体用法是参数校验和字段初始化的一行式书写：

public Person(string name) => Name = name ?? throw new ArgumentNullException(nameof(name));

这行代码等价于：

public Person(string name) { Name = name ?? throw new ArgumentNullException(nameof(name)); }

这里=>右侧是一个赋值表达式，不是返回语句。编译器生成构造函数时，会先把表达式作为语句放在构造函数体里，再插入默认的 base 调用逻辑。用这个写法要注意：构造函数表达式体适合只有一个语句的情况。如果构造函数里有多步初始化，比如先校验、再赋私有字段、还要触发事件，就不要硬套表达式体，老老实实写大括号才是对的可读性选择。

析构函数的表达式体写法相对少见，但确实存在：

~Person() => Console.WriteLine("Person finalized");

这种写法把析构函数体压缩成一行，对于只有日志输出或资源释放单行调用的析构函数来说很合适。但我个人建议析构函数尽量别用表达式体。析构函数涉及非托管资源释放时，往往需要 try/finally 或多行清理逻辑，单表达式约束会逼着你把复杂逻辑塞进一行，反而害了代码质量。

3.2 get 和 set 访问器：箭头右侧可以是赋值语句

这是我认为最值得展开讲的一种用法。C# 7 开始，属性的 get 和 set 访问器分别支持表达式体。看一个标准写法：

private string _name; public string Name { get => _name; set => _name = value; }

这里有两个需要区分的语义：

• get => _name;等价于get { return _name; }，箭头右侧是返回表达式。
• set => _name = value;等价于set { _name = value; }，箭头右侧是赋值语句。

很多人第一次看到set => _name = value;会愣一下，因为它看起来不像一个返回值的方法体。这正是表达式体成员和 Lambda 的又一个重要区别：表达式体成员的箭头右侧可以是语句表达式，但 Lambda 的箭头右侧如果是语句，需要使用大括号代码块。编译器在访问器上下文里遇到=>时，会自动根据访问器类型决定生成 return 语句还是普通语句。

set 访问器表达式体最有价值的应用场景是带校验的赋值。比如：

private string _name; public string Name { get => _name; set => _name = value ?? throw new ArgumentNullException(nameof(value)); }

这个写法把“空值就抛异常，否则赋值”的完整逻辑压缩到一行，同时保持了可读性。也不仅限于 null 校验，任何单表达式赋值都适用：

public int Age { get => _age; set => _age = value < 0 ? 0 : value; }

这种简写让属性定义的关注点非常集中：读的时候怎么做、写的时候怎么做，一眼看完。我个人在实体类里大量使用这套写法，配合主构造函数（C# 12）之后，实体定义可以做到非常紧凑。

3.3 三种上下文对比：什么时候用哪种

为了把 Lambda、表达式体方法、表达式体访问器的区别彻底讲透，我把它们的语义差异整理成一个表：

可以看出，=>在这里只是一个语法标记，真正决定右侧语义的是上下文。这也是为什么有些人看别人的代码时总觉得“这是 Lambda 但又不太对劲”，因为直觉上 Lambda 和表达式体成员的箭头右侧都像表达式，但编译后的产物完全不同。

还有一个配置层的细节：表达式体是编译期语法糖，不依赖运行时特性。这意味着即使项目运行在旧版 .NET Framework 上，只要编译器支持 C# 6/7（Visual Studio 2015 以上即可），就能放心使用表达式体成员。它不会引入任何新的 IL 指令，纯属编译期代码转换。很多担心“老项目能不能用”的开发者，在知道这一点后都打消了顾虑。

4. 实操示例：用=>重构一个带校验的实体类

4.1 重构前后的完整对比

理论说再多，不如直接看一个完整的演进过程。假设手里有一个不那么讲究的实体类，写完是这样的：

public class Product { private string _name; private decimal _price; private readonly List<string> _tags = new List<string>(); public Product(string name, decimal price) { if (string.IsNullOrWhiteSpace(name)) { throw new ArgumentException("名称不能为空", nameof(name)); } if (price < 0) { throw new ArgumentOutOfRangeException(nameof(price)); } _name = name; _price = price; } public string Name { get { return _name; } set { _name = value ?? throw new ArgumentNullException(nameof(value)); } } public decimal Price { get { return _price; } set { _price = value < 0 ? 0 : value; } } public int TagCount { get { return _tags.Count; } } public string GetTag(int index) { return _tags[index]; } public override string ToString() { return $"{Name}: {Price:C}"; } }

这个类逻辑上没问题，但属性部分大量重复{ get { return ...; } }结构。用表达式体成员重构后：

public class Product { private string _name; private decimal _price; private readonly List<string> _tags = new List<string>(); public Product(string name, decimal price) : this(name, price, null) { } public string Name { get => _name; set => _name = value ?? throw new ArgumentNullException(nameof(value)); } public decimal Price { get => _price; set => _price = value < 0 ? 0 : value; } public int TagCount => _tags.Count; public string GetTag(int index) => _tags[index]; public override string ToString() => $"{Name}: {Price:C}"; }

从 40 多行压缩到 20 多行，逻辑没有任何变化。编译后的 IL 和重构前完全等价——这再次说明表达式体成员只是语法糖，不改变运行时行为。

4.2 逐步拆解关键行

上面示例里最值得细看的几行：

第一，带校验的 set 访问器：

set => _name = value ?? throw new ArgumentNullException(nameof(value));

这行的执行顺序是：先判断value是否为 null，是则抛异常，否则把 value 赋给_name。它等价于set { if (value == null) throw ...; _name = value; }。单行表达式中使用??加throw是 C# 里非常经典的组合，能把一条赋值逻辑上的前置校验写成一个表达式。

第二，构造函数里的校验。上面的重构版里我保留了大括号形式的构造函数，因为里面有两个if加赋值，超过了一个表达式的承载能力。如果想把构造函数也改成表达式体，就只能把校验逻辑压缩进单表达式，像这样：

public Product(string name, decimal price) => (_name, _price) = ( string.IsNullOrWhiteSpace(name) ? throw new ArgumentException("名称不能为空", nameof(name)) : name, price < 0 ? throw new ArgumentOutOfRangeException(nameof(price)) : price);

这个写法虽然合法，但可读性已经明显下降。我在实际项目中不会这么写。表达式体成员的核心价值是让简单逻辑更简单，不是让复杂逻辑变魔术。构造函数带多条件校验时，保持传统大括号写法更利于理解和调试。

第三，只读属性的表达式体：

public int TagCount => _tags.Count;

这行没有 get 关键字，因为整个属性就是 get 访问器的全部内容。编译器会生成一个只读属性。这种写法在 DTO、查询结果类、领域对象里非常常见。

4.3 什么时候别用表达式体

写了这么多年 C#，我对表达式体成员的使用原则总结成一句话：一个表达式能说清楚的事，用它；一个表达式说不清楚的事，别硬凑。

不适合使用的情况包括：

• 方法体需要多个语句，比如循环加返回值、临时变量参与中间计算、try/catch 包裹异常。
• 构造函数有多个校验分支，或需要调用多个初始化方法。
• 属性 set 访问器里有赋值之外的事件触发、日志记录等副作用。
• 接口实现方法包含注释说明时，大括号块更方便保留注释位置。

比如这段代码就不适合用表达式体：

public List<string> GetNames() { var result = new List<string>(); foreach (var item in _items) { if (item.IsActive) { result.Add(item.Name); } } return result; }

用表达式的写法要么借助 LINQ 强行压缩成一行，要么写成一串难以阅读的嵌套调用。强行单行化只会把简单问题复杂化。保持多行方法体的可读性，本身就是一种专业性。

5. 常见误用与排查：实操中的高频坑

5.1 把 set 访问器的=>当成 Lambda

这个误用我在代码评审里见过很多次。有些人在 set 访问器里想写多语句逻辑，于是尝试：

public string Name { get => _name; set => { _name = value; Console.WriteLine("updated"); } }

这段代码在 C# 里是合法的，但要注意：它并不是 Lambda 表达式块，而是表达式体 set 访问器里的一段代码块。实际上这种写法等价于：

set { _name = value; Console.WriteLine("updated"); }

写起来没问题，但已经偏离了表达式体的初衷。既然用了大括号，不如直接恢复完整 set 写法，代码更清晰。真正的断言是：表达式体访问器里只放一个赋值表达式，多语句请用传统访问器写法。

5.2 表达式体方法里尝试多行执行

新手写表达式体方法时常见的错误是试图把多行逻辑塞进一个箭头右侧：

public string BuildFullName() => FirstName + " " + LastName; // 这行没问题 Console.WriteLine("building"); // 编译错误

第二行完全没有编译的可能。表达式体的约束就是“一个表达式”，多语句必须使用传统方法体。如果有人告诉你“用 Lambda 就能写多行”，那是 Lambda 代码块语法(x) => { ... }，不是表达式体方法。这两个概念虽然都用了=>，但使用场景和限制完全不同。

如果你确实需要在单个表达式里完成多步逻辑，可以考虑用局部函数配合表达式体技巧，比如：

public string BuildFullName() => Concat(FirstName, LastName); private static string Concat(string first, string last) { Console.WriteLine("building"); return first + " " + last; }

这属于重构思路，但实际中直接写完整方法体更稳妥。

5.3 编译器版本不支持导致报错

表达式体构造函数和 set/get 访问器是 C# 7 才能用的特性。如果项目开着旧版本语言特性，或者 IDE 的默认语言版本低于 C# 7，就会收到这类报错：

CS8051: 功能“expression-bodied property”不可用，请使用 7.0 或更高版本的语言版本

排查这个问题的套路：先看项目的 LangVersion 设置。在老项目中，<LangVersion>可能被显式固定为6或7.0，属性访问器的表达式体写法就会报错。在 .csproj 里把 LangVersion 改成latest或者7.0以上即可。注意，修改 LangVersion 要考虑团队协作和项目兼容性，最好在项目层面确认没有问题再统一改。

5.4 过度使用带来的可读性灾难

表达式体成员不是越短越好。我有一个很深刻的教训：某次把一个多分支的映射逻辑压缩成三行链式表达式体方法，编译通过、测试也过了，但后来需求变化时，别人改起来需要拆开分析三行里每一步的数据流，成本反而变高了。

所以我现在的使用准则是：

• 属性 get 访问器，几乎无脑用表达式体。
• 属性 set 访问器带简单校验，用表达式体。
• 方法体只有一个 return 或一个调用，用表达式体。
• 需要两个以上临时变量或分支的方法，用传统写法。

另外还有一个小技巧值得分享：如果一段逻辑未来大概率会扩展，先把表达式体展开成完整方法体会省很多事。表达式的代码在重构时往往要改结构，而完整方法体只需要在 return 前插入逻辑。

5.5 常见误解速查表

在实际工作中遇到报错时，先按表排查语言版本、语法上下文、表达式数量三个维度，基本几分钟就能定位。

6. 最后分享一点我自己的使用心得

这个语法糖我用得最多的地方其实是 DTO 和数据实体的属性定义。一个包含十几个只读计算属性的类，用传统写法能撑满一屏，用表达式体成员只需要几行。特别是配合 C# 12 的主构造函数，一个实体类从定义到初始化可以做到非常紧凑，但可读性依然在线。

要说最容易被忽略的用法，我投给 set 访问器的表达式体。很多人知道属性 get 能用=>，却不知道 set 也能用。知道 set 能用的，又有一部分不知道箭头右侧可以直接写带校验的赋值表达式。这几个认知层级串起来，才算真正把这套语法吃透。

另外还有个建议：团队项目里如果要推广表达式体成员，最好在代码规范里明确边界。比如“属性访问器允许表达式体”“方法体超过一个表达式必须展开”“构造函数不强制使用表达式体”。有了边界，代码风格才不会被个人偏好带跑。没有边界的话，同一个项目里会出现极端精简派和保守完整派两种风格互相打架的情况，维护成本比代码本身高得多。

如果读完这篇文章你想做点什么，我建议把项目里那些只含一个 return 的传统属性和方法挑出来，用表达式体成员简化一遍。改完编译跑一遍测试，你会发现 IL 没有变化，但代码的呼吸节奏完全不同。这就是这个语法糖最初想带给你的东西：少一点仪式感，多一点表达力。