<p>扩展方法是静态方法的语法糖，需定义在非嵌套静态类中，调用前必须显式引入命名空间；C# 14 extension块仅为写法优化，语义等价且限制更多；无法重写实例方法，不访问私有成员，适用场景有限。</p>
WordCount 这类扩展方法不是“给类加新功能”，而是让调用方看起来像在调用实例方法——实际仍是静态方法调用，编译器自动补全第一个 this 参数。C# 14 引入的 extension 块语法只是写法更紧凑，语义和旧式 this 静态方法完全等价。
扩展方法必须定义在非嵌套静态类里
这是硬性限制，编译器会直接报错：CS1106 Extension method must be defined in a static class。常见踩坑点包括：
- 把扩展方法写在
Program类、Startup类或任何非静态类内部 - 用了
partial修饰但类本身没声明为static - 类加了
internal但调用方在另一个程序集，且没加[InternalsVisibleTo]
正确写法只有一种结构：
namespace MyExtensions
{
public static class StringHelper
{
public static int WordCount(this string s)
{
return string.IsNullOrEmpty(s) ? 0 : s.Split(' ', '.', '?', StringSplitOptions.RemoveEmptyEntries).Length;
}
}
}调用前必须引入命名空间，且不能省略 using
扩展方法不会自动出现在 IntelliSense 中，也不会被自动发现。哪怕类和调用代码在同一个项目、同一个命名空间下，也必须显式写 using MyExtensions;。否则编译器报错：CS1061 'string' does not contain a definition for 'WordCount'。
容易忽略的细节：
-
using必须写在调用文件顶部，不能只在某个方法里写 - 如果扩展方法定义在
MyExtensions.StringHelper，但你只写了using MyExtensions;（没写子命名空间），依然不生效 - .NET 6+ 的隐式 using（如
System）不会包含你自定义的命名空间
C# 14 的 extension 块写法不是替代，是补充
它只是语法糖，不是新机制。下面两种写法生成的 IL 完全一致：
// 传统写法（C# 3.0 起支持）
public static int WordCount(this string s) { ... }
<p>// C# 14 extension 块写法
extension(string s)
{
public int WordCount() { ... }
}但 extension 块有明确限制：
- 只能用于非泛型、非嵌套的静态类
- 块内不能定义泛型方法（比如
public T FirstOrDefault<T>()不合法） - 无法定义带
ref或out参数的扩展方法（因为extension块参数列表固定为单个接收者）
所以日常开发中，除非要批量定义多个同类型扩展成员（比如一整套 string 工具方法），否则没必要强行切到新语法。
扩展方法无法重写实例方法，也不参与虚方法调度
这是最容易误解的一点：扩展方法永远是“最后备选”。如果目标类型本身已有同签名的实例方法（比如 string.Length），你定义一个 public static int Length(this string s)，编译器会直接忽略它——调用 s.Length 永远走原生属性，不会触发你的扩展。
更隐蔽的问题：
- 扩展方法不能访问
private或protected成员，连internal都不行（除非跨程序集时配了[InternalsVisibleTo]） - 泛型约束（如
where T : IDisposable）必须写在方法声明上，不能写在extension块声明行 - 性能上无额外开销，但过度使用会让调用链变模糊——别人看到
s.WordCount()时，得翻命名空间才能确认这是扩展还是原生方法
真正需要扩展的场景其实很窄：当你无法修改源类型（比如第三方库的 HttpClient）、又不想包一层 wrapper 类时，扩展方法才值得用。其他时候，优先考虑组合或继承。
