模块初始化器提案已经被提升到 C# 9 候选资格。它就像 C#中的静态构造函数，但不是应用于一个类，而是应用于整个程序集。
这个特性从一开始就存在于 CLR 中，但是直到现在还没有被 C#公开。根据模块初始化器提案，它将作为对静态构造函数语法的修改而公开。
|
[
|
|
|
internal static class MyModuleInitializer
|
|
|
{
|
|
|
static MyModuleInitializer()
|
|
|
{
|
|
|
// 将模块初始化器放在这里
|
|
|
}
|
|
|
}
|
从这个例子中可以看到，模块级属性会被标记为类名。然后，该类的静态构造函数被提升到模块初始化器级别。
这个特性可能会带来优于普通静态构造函数的性能。Mark Smeltzer 写道：
当前，运行时采用 init 锁，用于对是否已处理静态构造逻辑进行双重检查。即使向类中添加一个静态只读字段，也会立即增加该类中任何成员的每次外部使用的开销。
能够以一种有保证的、可预测的顺序运行初始化逻辑，并且在模块初始化后没有任何运行时操作，这将是一个巨大的优势。
另一个好处是模块初始化器是可预测的；其中的所有代码都是按顺序运行的。对于静态构造函数，从程序集的角度来看，它们的运行顺序是不确定的。根据客户端代码的不同，类 A 的构造函数可以在类 B 之前或之后运行。
对于上面的引文，Mark Smeltzer 在评论中进行了澄清：
模块初始化器仍然有上述的好处，但是在最初评论时，我并没有注意到.NET Core 3.0 对分层编译的一些最新改进…
.NET Core 3.0+ 中的分层编译解决了只读静态成员访问的问题。要了解更多信息，请查看 https://github.com/dotnet/coreclr/issues/24571#issuecomment-492401619。这个特性在.NET Core 3.0 版本已经发布。
这个特性非常棒：运行时最初会根据需要生成快速编译但不是最优的 JIT 代码，然后执行它。然后，在后台，运行时会分析上下文和 IL 代码，以确定是否可以实现更优的 JIT 解决方案。如果是，它将重新编译 IL 代码，并将低速的 JIT 路径替换为最优的 JIT 路径。当然，在实现的过程中会有一些额外的复杂性，但这是基本的思想。
对于静态类初始化器和静态只读字段初始化器，运行时将生成带有初始化锁的首遍（first pass）代码。那可以防止初始化器运行两次。该锁定还会带来运行时性能损失。因此，一旦初始化器运行一次，优化器就会生成新的经过优化的访问器代码路径，不再进行任何锁定！
再说一下，我不清楚实现细节（我可以确定，跟踪有关访问器肯定很复杂，需要在初始化之后进行优化），但净收益相当大：运行时本身自动优化掉了使用静态初始化器和静态只读字段的性能损失。
术语说明：
.NET CLR 中的“模块”是一个包含 IL 代码的文件。“程序集”是由一个或多个模块组成的逻辑单元，其中一个模块被指定为头程序集。大多数.NET 语言被设计成只创建单模块 / 单文件程序集。因此，对大多数开发人员来说，这些术语是可以互换的。
VB 中的“模块”就是 C#所称的“静态类”。
“附属程序集”在某些方面类似于多模块 / 多文件程序集，但它是一个独立的概念。