拓展方法必须定义在静态类中且自身为static，首个参数用this修饰目标类型；不能访问私有成员，同名时实例方法优先；泛型需注意类型约束与推导。
拓展方法必须定义在静态类里
不是加个 static 就行，整个类都得是 static，否则编译器直接报错：the extension method requires a static class。很多人写完方法忘了包一层静态类，或者类里混了实例成员，结果死活不识别。
- 类名无所谓，但必须带
static修饰符，且不能有构造函数、字段、属性等非静态成员 - 拓展方法本身也必须是
static，第一个参数用this修饰，类型就是你要拓展的目标类型（比如this string s） - 命名空间要和调用处能“看到”，要么 using 引入，要么写全限定名
示例：
namespace MyExtensions
{
public static class StringExtensions
{
public static bool IsEmpty(this string s) => string.IsNullOrEmpty(s);
}
}
拓展方法不能访问私有/受保护成员
它本质是静态方法的语法糖，编译后就是普通静态调用，所以没特权——this 参数只是个普通参数，不是“进入对象内部”。想操作私有字段？不行。想重写虚方法？也不行。
- 适用场景：补足公共 API 缺失的常用逻辑，比如
"abc".ToTitleCase()、list.AsReadOnlyView() - 不适用场景：需要绕过封装、依赖内部状态、或要改变对象行为本质的地方
- 如果真需要深度干预，考虑继承（对可继承类）或包装器模式，而不是硬塞拓展方法
拓展方法和实例方法同名时，实例方法永远优先
这是 C# 明确规定的重载解析规则。哪怕拓展方法参数更匹配，只要目标类型自身有同签名的实例方法，就一定走实例方法。不会报错，也不会警告，容易误以为“拓展生效了”，实际根本没调到。
- 常见踩坑：给
IEnumerable写了个Count()拓展，结果发现调用时还是走 LINQ 的那个Count()—— 因为IEnumerable本身没，但ICollection有，而很多集合类型同时实现了这两个接口，编译器选了更具体的实例实现 - 验证方式：把拓展方法名改掉（比如叫
SafeCount()），再调用看是否生效 - 别试图靠参数类型“骗过”重载解析，C# 不会因为拓展方法更贴合就放弃已有的实例方法
泛型拓展方法要注意类型约束和推导失败
泛型拓展方法写起来方便，但一旦加了 where 约束，或者参数类型太模糊，编译器可能无法推导 T，导致“找不到合适的方法”错误，而不是你预想的“类型不满足约束”。
- 例如：
public static T FirstOrDefault—— 如果(this IEnumerable source, Func predicate) where T : class T是int，约束不满足，但错误信息可能只说“没有匹配的重载”，不提约束问题 - 解决办法：显式指定类型参数，如
list.FirstOrDefault(x => x.Length > 0) - 尽量让第一个
this参数承载足够类型信息，避免过度依赖后续参数推导
拓展方法看着轻巧，但它的作用域、绑定时机、重载优先级全是编译期决定的，运行时完全不参与。最容易被忽略的是命名空间引入和重载冲突——写完不生效，八成是没 using 对，或者名字撞上了已有方法。
