static在C#中明确划分“属于类型”与“属于实例”的边界，static方法不绑定任何对象实例，故this指针不存在，无法访问实例成员，编译器报CS0120错误。
直接说结论：static 在 C# 中不是“让方法变快”或“避免 new”的语法糖，而是明确划清「属于类型」和「属于实例」的边界——越早理解这点，越少掉进 NullReferenceException 或共享状态污染的坑。
为什么不能在 static 方法里访问 this 或实例成员
因为 static 方法压根不绑定到任何对象实例上，this 指针根本不存在。编译器会直接报错 CS0120：“非静态字段、方法或属性 'X' 需要对象引用”。
- 哪怕你写了
new MyClass()，也不能在static方法内部用this.SomeField - 想访问实例成员？必须显式传入对象引用，比如
public static void LogName(MyClass obj) { Console.WriteLine(obj.Name); } - 常见误操作：把原本该是实例方法的逻辑（如
Save()、Validate()）强行改成static，结果发现要传一堆参数才能凑齐上下文
static 类和 static 成员的初始化时机差异
static 类本身会在首次被访问时触发初始化；但其中的 static 字段和 static 构造函数的执行顺序有隐含规则——字段初始化先于 static 构造函数体执行。
- 如果字段初始化依赖另一个静态类，而那个类还没被加载，就可能触发意外的类加载链，甚至死锁（尤其在多线程 + 自定义
static构造函数时） -
static构造函数只运行一次，且不可被显式调用；它没有访问修饰符，也不能带参数 - 别指望靠
static字段赋值做复杂初始化（比如读配置、连数据库），出错时很难捕获和重试——应放到显式初始化方法中
什么时候该用 static 类，而不是普通类加 static 成员
当你确定这个类型**永远不需要实例化、永远不参与继承、所有功能都只依赖输入参数**时，才用 static class。
- 工具类（
Path.Combine、JsonSerializer.Serialize）适合；但带缓存、上下文、租户隔离的“工具”，就不适合——比如HttpClient就不该塞进static class里复用 -
static class会被编译器自动标记为sealed，且禁止写任何实例构造函数——这是保护机制，不是限制 - 反模式示例：把日志记录器包装成
static class Logger，结果无法切换实现、无法注入配置、无法按作用域控制输出格式
最容易被忽略的一点：静态成员的生命周期与 AppDomain（或现在的 AssemblyLoadContext）强绑定，只要程序没退出，它就一直占着内存，且所有线程共享。这意味着——改一个 static 字段，所有地方立刻可见；但没加锁的话，多线程写它就是竞态灾难。
