static 关键字在 C# 中表示成员属于类型本身而非实例，所有实例共享同一份静态数据或逻辑；它不可用于索引器、析构函数或非类/结构/接口类型，且静态方法必须通过类型名（如 MyClass.Method()）而非实例调用，否则编译报错 CS0120。
static 关键字在 C# 中不是“可选优化”，而是语义强制：一旦加了，就彻底脱离实例生命周期，所有实例共享同一份数据或逻辑。用错地方会直接导致状态污染、线程不安全、测试困难——尤其在 ASP.NET Core 这类多请求共存环境中。
为什么不能用 new MyClass().StaticMethod() 调用静态方法
这不是语法限制，而是设计契约：静态成员属于类型本身，和任何对象实例无关。this 在静态上下文中根本不存在，所以编译器会报 CS0120 错误：“非静态字段、方法或属性 'X' 需要对象引用”。常见错误包括：
- 在实例方法里写
this.MyStaticHelper()（应改为MyClass.MyStaticHelper()） - 试图在构造函数中用
this.staticField = 1（this不合法，直接赋值staticField = 1即可） - 把
static方法声明在struct里却忘了它不能有实例字段——结构体的静态成员是允许的，但容易误以为“结构体不能有 static”
static class 和 class + static 成员的区别在哪
表面看都是“只能调用静态方法”，但底层约束完全不同：
-
static class Utility：编译器强制禁止继承、实例化、含任何实例成员；连私有构造函数都不用写；IL 层面标记为sealed和abstract -
class Helper { public static void Do() {} }：可以被继承（哪怕没意义），能加实例字段/方法，也能加私有构造函数来防实例化——但这只是“约定”，编译器不管你有没有偷偷 new 出来 - 性能上无差异，但
static class更安全：比如你后期重构时误加了一个public string Name { get; set; }，前者直接编译失败，后者悄无声息地埋下共享状态雷
静态构造函数什么时候执行？为什么不能带参数
static 构造函数只执行一次，且时机由 CLR 控制：首次访问该类型的任意静态成员，或首次创建该类型的实例（哪怕类型本身是 static class，这条不适用）时触发。它没有访问修饰符，不能带参数，也不能被显式调用。
典型误用场景：
- 在
Main方法开头就写MyStaticClass.Initialize();—— 实际上只要第一次用到MyStaticClass.SomeValue就已触发，手动调用是冗余甚至危险的（可能重复初始化） - 试图在静态构造函数里读取
ConfigurationManager.AppSettings或连接数据库——如果配置缺失或 DB 不可用，整个类型将永久不可用，后续所有调用都抛TypeInitializationException - 在 ASP.NET Core 中依赖
IWebHostEnvironment等注入服务？不行。静态构造函数无法接收依赖，必须用其他方式（如延迟初始化的Lazy<t></t>或单例服务）
静态字段跨请求共享，ASP.NET Core 里怎么避坑
这是最隐蔽也最常出问题的地方。例如：
public static class Counter
{
public static int TotalRequests; // 所有请求共用这一个 int
}
在高并发下，TotalRequests++ 不是原子操作，结果会丢失。更糟的是，如果它是个集合：
public static class Cache
{
public static Dictionary<string, object> Items = new();
}
多个请求同时 Add 或 Remove 会直接抛 InvalidOperationException：“集合已被修改”。解决方式不是“少用 static”，而是明确选择：
- 需要全局唯一状态 → 用
ConcurrentDictionary<string object></string>或Interlocked.Increment(ref counter) - 需要按请求隔离 → 别用 static，改用 scoped service 或
HttpContext.Items - 需要初始化后只读 → 用
static readonly+ 静态构造函数初始化，之后绝不修改
真正难处理的不是“怎么写”，而是“怎么意识到它正在跨请求共享”——很多 bug 表现为偶发、不可复现，根源就在某个被忽略的 static 字段上。
