扩展方法必须定义在顶级静态类中且无实例成员，调用前需 using 命名空间，无法访问私有/内部成员，同名实例方法优先于扩展方法。
扩展方法不是“加个 this 就能用”，漏掉任一硬性条件，编译器立刻报错 CS1106 或 CS0702，根本跑不起来。
扩展方法必须写在静态类里，且不能嵌套
这是最常踩的坑：把扩展方法直接塞进 Program.cs 的顶层语句块、或者放在某个普通类内部（哪怕加了 static），都会失败。
- 静态类必须是顶级的、非泛型的、不可继承的 —— 例如
public static class StringExtensions - 类里不能有任何实例成员（字段、属性、构造函数等），否则报
CS0702 - 不能是嵌套类（比如写在
class Utils { public static class Ext { ... } }里），否则扩展方法根本不会被发现
调用前必须 using 命名空间，IntelliSense 不会自动提示
即使扩展方法和调用代码在同一个项目、甚至同一个文件夹，只要没加 using，IDE 就当它不存在 —— 这不是 bug，是 C# 的作用域规则。
- 定义在
namespace MyLib.Extensions，就必须在调用文件顶部写using MyLib.Extensions; - 多个命名空间里有同名扩展方法（比如都叫
ToInt()），不加限定会触发CS0121：“对重载方法的调用不明确” - 想临时验证是否生效？删掉
using，看 IDE 是否立刻标红；补上后，点 “.” 应该能弹出方法名
this 参数只是语法糖，无法访问私有/内部成员
扩展方法本质就是编译器帮你把 obj.DoSomething() 翻译成 MyExt.DoSomething(obj)，它和普通静态方法没有权限差异。
- 在扩展方法里写
obj._privateField或obj.InternalMethod()，直接报CS0122：“因为其保护级别而不可访问” - 别想着靠扩展方法“绕过封装”——真需要访问内部状态，说明类型设计可能有问题，优先考虑加只读属性或开放
internal接口 - 反射能突破限制，但那就不是扩展方法了，而且破坏语义、拖慢性能
C# 14 的扩展块语法更简洁，但兼容性需留意
如果你用的是 C# 14+（.NET 8 SDK 及以上），可以用新语法避免重复写 this 参数：
public static class StringExtensions
{
extension(string str)
{
public int WordCount() => str.Split(' ', '.', '?', StringSplitOptions.RemoveEmptyEntries).Length;
}
}- 旧写法仍完全有效，新语法只是减少样板代码
- 但团队若混用不同 SDK 版本，C# 14 语法在低版本编译器下直接报错，上线前务必确认构建环境
- 扩展块里的方法仍是静态的，依然受所有前述约束（静态类、
using、无私有访问等）
最容易被忽略的一点：扩展方法永远是“最后备选”。如果目标类型本身有同名实例方法（哪怕参数不同），编译器优先选实例方法，扩展方法会被静默忽略 —— 调试时发现方法没走预期逻辑，先查是不是撞名了。
