扩展方法是编译器将形如obj.Method()重写为StaticClass.Method(obj)的机制，必须定义在非嵌套静态类中，首参数带this修饰符，用于提升API可读性与复用性。
扩展方法不是语法糖，而是编译器在调用侧自动重写为静态方法调用的机制；它不改变类型本身，也不支持继承链上的多态，但能显著提升 API 可读性与复用性。
扩展方法必须定义在非嵌套静态类中
这是硬性限制，编译器会直接报错 CS1106（“扩展方法必须在静态类中定义”）。如果你把 WordCount 写在 Program 类内部、或者加了 public class Helper 嵌套在另一个类里，VS 或 dotnet build 都会拒绝编译。
常见错误现象：
- IntelliSense 不显示方法，即使命名空间已引入
- 调用时提示
"string" does not contain a definition for 'WordCount'
正确做法：
- 新建一个独立的
.cs文件，如StringExtensions.cs - 用
public static class StringExtensions声明（不能是internal或嵌套） - 确保该类所在命名空间被客户端代码用
using引入
this string str 参数声明位置不能错
扩展方法本质是静态方法，第一个参数带 this 修饰符，且必须是目标类型的实例。这个参数不是你传进去的，而是编译器从调用对象自动绑定的。
错误写法示例：
public static int WordCount(string str) // ❌ 缺少 this public static int WordCount(this string? str) // ⚠️ 可空引用类型需谨慎（C# 8+） public static int WordCount(this StringBuilder sb) // ❌ StringBuilder 不是 string，无法对 string 实例调用
正确写法：
public static int WordCount(this string str)
{
if (str == null) return 0;
return str.Split(' ', '.', '?', StringSplitOptions.RemoveEmptyEntries).Length;
}
注意点：
-
this必须紧贴类型声明前，不能有空格或换行隔开 - 参数名（如
str）在调用时不出现，只在方法体内使用 - 若目标类型支持可空引用（
string?），建议显式判空，避免运行时异常
C# 14 的 extension 块写法更紧凑但有约束
C# 14 引入了 extension 块语法，允许在一个块内集中定义多个成员（方法、属性、运算符），但目前仅支持单个接收者类型，且不能泛型化。
例如以下合法写法：
namespace CustomExtensions;
public static class StringExtensions
{
extension(string str)
{
public int WordCount() => str.Split(' ', '.', '?', StringSplitOptions.RemoveEmptyEntries).Length;
public bool IsPalindrome() => str == new string(str.Reverse().ToArray());
}
}
容易踩的坑：
-
extension块不能出现在泛型类中（如public static class Extensions<t></t>） - 块内不能定义静态方法（所有成员默认是实例扩展）
- VS 2022 17.10+ 和 .NET 8 SDK 才完整支持，旧版本会报
CS8901 - 不能像传统方式那样给不同接收者（如
this int和this string）共用一个类
调用前必须确保 using 指令生效且无歧义
扩展方法不会自动“全局可见”，哪怕类和方法都写对了，没加 using 就等于不存在。
典型问题场景：
- 多个命名空间下有同名扩展方法（比如两个
WordCount），编译器报CS0121：“调用含糊不清” - 项目引用了 NuGet 包（如
MoreLinq），其扩展方法与自定义的冲突 - 在
.NET 6+的隐式 using 启用后，自定义命名空间未被列入global using列表
解决建议：
- 明确写出
using CustomExtensions;，不要依赖隐式 using - 发生歧义时，用全限定名调用：
CustomExtensions.StringExtensions.WordCount(s) - 检查
Directory.Build.props或xx.csproj中是否禁用了隐式 using
真正难的不是写对语法，而是判断某个操作值不值得做成扩展方法：它应该高频、语义清晰、不破坏原有类型契约。比如给 IEnumerable<t></t> 加 TakeRandom(3) 是合理的，但给 DateTime 加一个只在你项目里用一次的 NextWorkday()，不如直接写个普通静态工具方法。
