扩展方法必须定义在静态类中且第一个参数用this修饰，否则报CS1106；静态类不能含实例成员（CS0702）或继承；需using引入命名空间才能被识别，不可访问私有/内部成员，本质是语法糖。
扩展方法必须定义在静态类里
不是所有静态方法都能当扩展方法用，C# 编译器只认一种特殊签名：第一个参数带 this 修饰符的静态方法，且它所在的类本身必须是静态的。漏掉任一条件，编译器直接报错 CS1106 —— “扩展方法必须在非泛型静态类中定义”。
- 静态类不能有实例构造函数，也不能被继承，否则扩展方法无法被发现
- 如果类里混了非静态成员，编译器会报
CS0702：“不能在静态类中声明实例成员” - 命名上别用
Extensions当类名就万事大吉——关键是语义清晰，比如StringExtensions或EnumerableExtensions更易维护
调用时需要 using 引入命名空间
扩展方法不会自动出现在 IntelliSense 里，哪怕你把它写在同一个项目里。根本原因是 C# 的查找机制只看当前作用域的 using 指令，而不是文件位置或程序集引用。
- 没加
using YourNamespace;，就算方法存在，也会提示“未找到适用于…的适用扩展方法” - 多个命名空间含同名扩展方法（比如两个
ToInt()），不加限定会触发 CS0121：“对重载方法的调用不明确” - 常见误操作：把扩展方法写在
Program.cs的顶层语句块里——不行，顶层代码不能包含静态类，得单独建.cs文件
扩展方法不能访问私有/内部成员
它本质是语法糖，编译后变成普通静态方法调用，this 参数只是个普通形参。所以它和调用方之间没有“对象上下文”，也不具备任何访问权限提升。
- 试图在扩展方法里写
obj._field或obj.SomeInternalMethod()，编译失败，错误是CS0122：“因为其保护级别而不可访问” - 想“绕过”访问限制？不行。反射可以，但那就不是扩展方法了，而且破坏封装、影响性能
- 真正该做的：如果频繁需要访问内部状态，说明类型设计可能有问题，考虑开放只读属性，或把逻辑移到类型内部
泛型扩展方法要注意类型约束和推导
泛型扩展方法看着灵活，但类型参数一旦没约束好，要么调用失败，要么行为不符合预期。尤其在链式调用中，类型推导容易“断掉”。
- 比如
public static T FirstOrDefault<t>(this IEnumerable<t> source, Func<t bool> predicate)</t></t></t>，如果没写where T : class，传值类型时可能引发装箱/拆箱开销 - 省略泛型实参时，C# 尝试从参数推导，但若第一个参数是
object或dynamic，推导失败，必须显式写成list.FirstOrDefault<string>(x => x.Length > 0)</string> - 别给扩展方法加太多泛型参数，三个以上基本意味着可读性已受损，也增加调用方理解成本
事情说清了就结束。最常卡住人的，其实是命名空间没引入，以及把扩展方法当成“能突破访问限制的魔法”。它只是让调用更顺手，不是万能胶。
