C# 14 实战三连：field 关键字、extension 成员与 null 条件赋值

.NET 10 带来的 C# 14 不是一场 syntax earthquake，但里面藏着三件日常写码频率极高的改进。这篇不讲新闻稿，只讲用起来什么感觉、编译器在背后做了什么、以及哪里会静默踩坑。

先说结论

1. field 关键字干掉了"一行属性 + 一个字段 + 一坨 setter 校验"的样板代码：属性访问器里直接用 field，编译器自动合成 backing field，不再需要手工声明字段。
2. extension 成员让扩展能力从"只能加方法"升级到"能加属性、索引器、静态成员"：新的 extension 块替代了散落的 this 参数。
3. null 条件赋值 a?.B = c 合法了：以前必须 if (a != null) a.B = c;，现在一行搞定，且支持 += 等复合赋值。
4. 三者都是编译期特性，运行时零新依赖：老项目把 LangVersion 升到 14 就能用，不需要升级目标框架到 .NET 10（field 与 extension 成员需要 SDK 支持，但产物可在旧运行时跑）。
5. 都有明确的"静默失效"坑，后文逐一列出。

机制：编译器替你做了什么

field 关键字

C# 13 之前，想给自动属性加一点校验逻辑，就得自己声明字段：

private int _age;
public int Age
{
    get => _age;
    set
    {
        if (value < 0) throw new ArgumentOutOfRangeException(nameof(value));
        _age = value;
    }
}

C# 14 开始，访问器里的 field 是一个上下文关键字，指向编译器合成的 backing field：

public int Age
{
    get;
    set
    {
        if (value < 0) throw new ArgumentOutOfRangeException(nameof(value));
        field = value;
    }
}

编译器行为：只要属性不是自动实现的、且某个访问器里用了 field，就会合成一个私有 backing field（命名规则与现有 auto-property 一致，带编译器生成标记）。get 里同样可以读 field，比如做"只允许改小"的逻辑。注意 field 是上下文关键字：属性所在类型里如果恰有个字段叫 field，访问器里的 field 仍解析到那个字段，这是为了兼容老代码。

extension 块

扩展属性是 C# 最大的语法欠账之一。C# 14 用新的 extension 块解决，接收者参数写在块头部：

public static class StringExtensions
{
    extension(string source)
    {
        public bool IsBlank => string.IsNullOrWhiteSpace(source);

        public bool TrySplit(char sep, out string left, out string right)
        {
            var i = source.IndexOf(sep);
            if (i < 0) { left = source; right = string.Empty; return false; }
            left = source[..i]; right = source[(i + 1)..]; return true;
        }
    }
}

调用端体验与普通实例成员完全一致：s.IsBlank、s.TrySplit(',', out var l, out var r)。编译器把它降级为静态方法调用，接收者作为第一个参数传入——所以运行时层面没有魔法，也不会产生委托分配。老的 this 参数写法仍然合法，两者可共存于同一静态类，但建议新代码统一走 extension 块。

null 条件赋值

customer?.Profile = newProfile;        // customer 为 null 时整体为 no-op
counter?.Hits += 1;                    // 复合赋值同样支持

要点：左侧是 null 条件成员访问时，编译器只对每个非空接收者执行赋值；a?.B.C = v 这类链式写法也按同样规则逐段判空。??= 略有特殊性：目标为 null 接收者时不会求值右侧表达式，语义和读操作一致。

容易踩的坑（静默失效类）

坑 1：field 与 init 访问器不兼容，但报错时机可能晚于预期。 使用 field 的属性不能带 init 访问器——因为 init 赋值路径不走你写的 set 校验逻辑，会把 backing field 的不变式打穿，编译器直接拒绝。真正的静默坑在另一侧：属性带 set 时，构造函数里如果直接给 backing field 类似逻辑赋值，或者团队里有人把属性改成 field 写法后忘了对象初始化器赋值会走 setter——setter 里抛异常的时机从"以前构造字段时不抛"变成"对象创建时就抛"，这是行为变化而非编译错误，测试覆盖不足时容易漏掉。

坑 2：extension 属性不会参与接口绑定和反射查找。 s.IsBlank 绑定的是编译期静态类型决定的扩展成员，如果变量类型是 object，编译直接失败（和扩展方法一样）；更隐蔽的是，typeof(string).GetProperty("IsBlank") 返回 null——扩展属性在运行时根本不是那个类型的成员。序列化器、依赖按属性名反射的 ORM、Expression 解析器都会无视它。另外不要试图对基类已有实例属性"扩展覆盖"，调用端静态类型决定绑定，同名扩展成员在派生类型变量上会静默切换绑定目标，属于极难排查的那类 bug。

坑 3：a?.B = c 在表达式里返回的是赋值后的接收者链，不是被赋的值。 如果你习惯把赋值嵌进别的表达式（var x = (a?.B = c);），拿到的语义与直觉可能有偏差，且可读性很差——赋值当表达式用的场景建议保持独立语句。

边界与不适用场景

• field 不适合跨越多字段的一致性逻辑（比如同时校验 Name/NameEn 的联动），那是构造函数或方法的职责；也别在 get 里做昂贵计算，它仍是字段读语义。
• extension 块无法访问接收者私有状态（本来就是外部静态类），不能被 override，不参与虚分派。需要多态行为时用接口，别用扩展属性模拟。
• null 条件赋值对 struct 接收者要注意装箱语义与局部副本问题；对可空值类型 int?，x?.Value = 5 这类写法语义上等价于判空后整体替换，与引用类型不同。

选型建议

场景	建议
属性需要校验/通知等 setter 逻辑	用 field，替代手写 backing field
给第三方/基础类型补"名词"能力（属性、索引器）	用 extension 块，而不是绕路写 Get 方法
反射、序列化、表达式树消费的成员	必须是真实成员，扩展成员不可用
判空赋值	a?.B = c 替代 if 判空，保持独立语句

最后一段最小可复现代码（.NET 10 SDK，<LangVersion>preview</LangVersion> 或 14 即可编译）：

var c = new Customer { Name = "kenny" };
Console.WriteLine(c.Name.IsBlank);   // False
c.Score?.Total += 10;                // Score 为 null 时无操作

public class Customer
{
    public string Name { get; set => field = value.Trim(); }
    public Score? Score { get; set; }
}
public class Score { public int Total { get; set; } }

public static class Extensions
{
    extension(string s)
    {
        public bool IsBlank => string.IsNullOrWhiteSpace(s);
    }
}

C# 14 的这三件套都不改变运行时模型，价值全在"把错误提前到编译期、把样板代码压缩掉"。升级成本几乎为零，建议中级以上项目直接开启。