扩展方法必须定义在静态类中且为静态方法，首参数用this修饰目标类型；调用时像实例方法，但需using引入命名空间，否则无法识别，本质是编译器语法糖。
扩展方法必须定义在静态类里
扩展方法本质是静态方法，但调用时像实例方法。C# 编译器只认得「声明在静态类中的静态方法」且第一个参数带 this 修饰符的才算扩展方法。漏掉任意一个条件，编译直接报错 CS1106：扩展方法必须在静态类中定义。
- 静态类不能被实例化，也不能继承，只用来组织工具方法
- 类名无特殊要求，但惯例用
Extensions结尾（如StringExtensions） - 如果类不是静态的，哪怕方法加了
this，也不会被识别为扩展方法，调用时会提示“未找到该方法”
this 参数必须是第一个，且类型决定可扩展的对象
扩展方法的第一个参数写成 this T target，其中 T 是你要扩展的类型。这个类型决定了哪些对象能“点出”这个方法——比如 this string s，那只有 string 类型变量才能调用；this IEnumerable<int> list</int>，就只能用于 IEnumerable<int></int> 或其子类型。
- 不能把
this放在第二位或后面，否则编译失败：CS1106 - 支持泛型约束，例如
public static T FirstOrDefault<t>(this IEnumerable<t> source) where T : class</t></t> - 可以扩展接口、抽象类、甚至
object，但过度泛化容易引发歧义和性能隐患
调用前必须引入命名空间，否则方法不可见
扩展方法不是自动加载的。即使定义好了，如果当前文件没用 using 引入它所在的命名空间，IDE 不会提示，编译器也报错 CS1061：“xxx 不包含定义的成员”。这不是方法写错了，只是“找不到”。
- 检查扩展方法所在类的
namespace，确保调用处有对应using - 常见坑：扩展类放在默认命名空间（无
namespace块），而调用文件在显式命名空间下，此时必须用using static或完整限定名调用 - VS 中按
Ctrl + .通常能自动补全using，但前提是项目已引用该类所在程序集
扩展方法不能访问私有成员，也不能重写实例方法
扩展方法运行时跟普通静态方法一样，它没有 this 实例上下文，所以无法读写被扩展类型的私有字段或调用私有方法。另外，如果类型本身已有同签名的实例方法，实例方法永远优先，扩展方法会被静默忽略。
- 想操作私有状态？不行。只能靠公开 API 组合，或改用代理/装饰器模式
- 命名冲突时不会报错，但调用结果一定是实例方法——这点极易误判，调试时要留意实际执行的是哪个
- 性能上无额外开销，编译后就是普通静态方法调用，但频繁使用可能掩盖设计问题（比如本该是类职责却堆到扩展里）
扩展方法看着轻巧，但它的作用域、可见性、优先级都依赖编译期规则，而不是运行时机制。最容易卡住的地方不是语法写错，而是命名空间没导出、或者以为它能绕过封装边界。
