为什么.NET静态字段初始化在在线编译器失败但VS运行正常

运行差异的根本原因 #

这个差异是.NET规范中静态类型初始化的beforefieldinit特性的灵活执行规则导致的：

• 当静态类型没有显式声明静态构造函数时，C#编译器会为该类型添加beforefieldinit元数据标记。该标记允许CLR在第一次访问该类型静态成员之前的任意时间点提前执行静态字段初始化逻辑，具体触发时机由CLR的运行策略决定，受运行时版本、优化级别、运行环境影响，没有统一的固定时序。
• 你代码中的Foo静态类没有显式静态构造函数，因此带beforefieldinit标记：
  • 在线编译环境通常默认开启较高的运行优化等级，CLR会在Main方法开始执行前就提前完成所有带beforefieldinit标记类型的静态初始化，此时Factory还未被赋值为null，触发空引用异常，包装为TypeInitializationException抛出。
  • 本地Visual Studio默认使用Debug配置运行，关闭了代码优化，CLR的策略会延迟静态初始化到第一次访问静态成员的前一刻执行：直到Console.WriteLine(Foo.foo)执行时才触发Foo的静态初始化，此时Factory已经完成赋值，所以能正常输出1。

不能认定Visual Studio构建的代码始终能正常运行 #

该代码的运行逻辑本身是不稳定的，不受构建工具保证：

• 如果你把本地项目切换到Release配置开启优化，大概率会复现和在线编译环境一样的崩溃问题。
• 即使当前版本的.NET运行时在Release下也能正常运行，后续.NET版本更新、更换运行时（比如从CoreCLR切换到Mono、AOT编译）都可能改变静态初始化的触发策略，导致代码崩溃。

稳定修复方案 #

把Foo类中注释掉的空静态构造函数static Foo() {}恢复即可：
显式声明静态构造函数后，编译器会移除beforefieldinit标记，此时CLR会严格保证静态初始化的时机为第一次访问该类型的静态成员前一刻，就能确保Factory完成赋值后才会执行Foo.foo的初始化逻辑，所有环境下都能稳定运行。

内容的提问来源于stack exchange，提问作者user16520881