扩展C#：关于扩展属性的迷思与真相

C#中的扩展属性：想要却不可得（以及如何绕过）

想象一下这种情况：你正在使用一个库，其中 Person 类有一个 FullName 属性。一切都很完美，但问题来了——你需要添加一个计算属性 AgeInDays，用于根据出生日期计算年龄（以天为单位）。你已经习惯了 扩展方法，于是想：“为什么不能做一个 扩展属性 呢？”

然后你上了 Stack Overflow，看到一个有数千浏览量的提问：“C# 有扩展属性吗？”——然后失望地读到答案：“不，官方不支持。” 但别急着关掉标签页！在本文中，我们不仅会分析为什么没有扩展属性，还会找到优雅的替代方案，且性能毫不逊色。

为什么C#不添加扩展属性？历史背景

首先，关键点在于：扩展属性 并非一时兴起，而是社区长期以来的诉求。早在 2016 年，GitHub 上就出现了相关提议（C# 功能请求），但至今仍未实现。为什么？

• 编译器的复杂性：与方法不同，属性具有 getter 和 setter，必须绑定到特定实例。在语法层面扩展这种逻辑需要对编译器进行重大修改。
• 与索引器的冲突：C# 中的属性和索引器紧密相关。添加扩展属性可能会造成歧义。
• 其他功能的优先级更高：C# 团队专注于 record、模式匹配 和 静态抽象成员（C# 11），这些功能对大多数场景更有用。

但缺乏官方支持并非绝路。让我们看看经验丰富的开发者如何解决这个问题。

扩展方法：你的主要工具（但有些细节）

最直接的方法是使用 扩展方法 代替属性。不用 person.AgeInDays，而是写 person.GetAgeInDays()。这可行，但破坏了代码的一致性：在其他代码中你使用属性，这里却突然变成了方法。

public static class PersonExtensions{    public static int GetAgeInDays(this Person person)    {        return (DateTime.Now - person.BirthDate).Days;    }}

// 使用：var age = person.GetAgeInDays(); // 可行，但不美观

缺点：代码可读性降低，尤其是在 LINQ 调用链中。优点：从性能角度看完全免费——调用扩展方法与普通静态方法没有区别。

替代方案 #1：静态工厂与辅助类

如果你需要一个基于数据计算的“属性”，可以创建一个静态辅助类：

public static class PersonHelper{    public static int AgeInDays(Person person) => (DateTime.Now - person.BirthDate).Days;}

// 使用：var age = PersonHelper.AgeInDays(person);

这比扩展方法更诚实：一眼就能看出这是一个辅助函数。但依然不是属性。

替代方案 #2：属性与源代码生成器

对于复杂场景（例如，为 NuGet 包中的类添加属性），可以使用 源代码生成器。它们从 .NET 5 开始引入，允许在编译阶段生成代码。你编写一个属性，生成器会创建包含所需属性的分部类。

[AutoExtensionProperty(typeof(Person), nameof(Person.BirthDate))]public partial class PersonExtensions{    // 生成器将创建 AgeInDays 属性}

// 生成的代码：public partial class PersonExt