C#语句并不会直接被CPU执行。开发者生成的项目经过Roslyn编译器处理后，得到的是包含IL指令、元数据和资源清单的.NET程序集。真正负责把IL转换为本机代码的是CLR中的JIT编译器，这一过程发生在运行时，而不是编译期。因此，理解IL与CLR的协作方式，是深入掌握.NET性能调优、逆向工程和跨平台发布的前提。
很多开发人员日常只关注C#语法和业务实现，却忽视了程序集内部究竟放了什么。实际上，无论是.exe还是.dll，在.NET Core和.NET 5+的体系下都不是CPU可以直接执行的原生映像。它们遵循PE文件格式，但核心存储的是一套与具体硬件无关的中间语言。当程序运行时，CLR介入加载、验证和编译，最终才交付给操作系统和处理器。下面从编译器的产物说起，逐步拆解这条链路。
一、C#编译前端：源码如何变成IL与元数据
Roslyn编译器会将C#源码解析为语法树，经过语义分析和绑定后生成IL。这个阶段的产物并不是机器码，而是一种基于堆栈的指令集。例如一个简单的加法方法，在C#里只写一行返回语句，编译成IL后会变成多条指令：先加载两个参数到求值栈，再执行加法，最后将结果返回。这种堆栈式设计使得IL与寄存器架构解耦，后续JIT可以在不同平台上进行寄存器分配。
查看IL最直观的方式是使用ildasm或ILSpy反编译程序集。下面是一段C#方法及其对应的IL代码，可以看到变量和参数如何被压栈、操作、存储：
public int Add(int a, int b)
{
return a + b;
}
.method public hidebysig instance int32 Add(int32 a, int32 b) cil managed
{
.maxstack 2
.locals init (int32 V_0)
IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: add
IL_0003: stloc.0
IL_0004: br.s IL_0006
IL_0006: ldloc.0
IL_0007: ret
}
这段IL虽然看起来啰嗦，但它清晰地反映了执行模型。除了指令本身，程序集中还保存着完整的元数据：类型定义、方法签名、属性、特性以及程序集引用关系。元数据的作用不只是反射，CLR在执行时也要依靠它完成类型安全校验、方法分派和垃圾回收中的对象布局计算。程序集清单还会记录版本号和依赖的程序集名称，缺少其中任何一项都可能导致运行时加载失败。
另外，程序集里还有一个特殊的类型<Module>，它负责存放全局函数和模块初始化代码。在C#中虽然不能直接定义全局函数，但编译器会为某些特性生成模块级方法。了解这些细节，有助于解释为什么有时程序集尺寸会比预期大，以及为什么仅修改一个常量字符串就可能影响整个模块的哈希值。
二、CLR加载与JIT执行：从方法调用到机器码
CLR全称公共语言运行时，是.NET程序的执行引擎。它由多个子系统组成：类加载器负责查找和加载程序集，JIT编译器将IL方法转换为本机指令，垃圾回收器管理堆内存，异常处理系统统一处理受控异常。启动一个托管程序时，CLR首先创建默认应用程序域，加载核心库，然后找到入口点方法并开始执行。入口点方法在第一次调用时会被JIT编译，而不是在程序启动时一次性编译所有代码。
JIT编译的基本单位是方法，而不是整个模块。当一个方法第一次被调用时，CLR会先检查该方法是否已有对应的本机代码，如果没有，则触发JIT编译。编译完成后，方法表会更新为指向本机代码的地址，后续调用直接跳转，不再经过IL解释。这也是为什么.NET程序常常出现首次调用较慢、二次调用明显变快的现象。对于泛型方法，CLR会根据值类型和引用类型采用不同的代码共享策略：所有引用类型实参共享同一份本机代码，而每个不同的值类型实参可能生成独立版本。
JIT编译过程中还会进行IL验证，确保栈操作平衡、类型安全且没有越界访问。验证失败的代码会抛出InvalidProgramException，这也是动态生成IL时需要特别注意的地方。除了普通JIT，还有ReadyToRun镜像，它在编译期预生成了部分本机代码，减少启动时的JIT工作量。不过ReadyToRun仍然保留IL和元数据，以便在需要时进行回退编译或跨平台适配。
类型加载同样重要。CLR不会在程序集加载时立即初始化所有类型，而是采用惰性初始化：只有首次访问静态字段、创建实例或调用静态方法时，类型构造器才会运行。方法表为每个类型维护虚方法槽位，接口分派则依赖额外的接口映射表。这些数据结构共同决定了虚调用和接口调用的性能差异，也解释了为什么接口分派在深层继承或泛型接口场景下会略慢于类虚方法调用。
三、JIT优化与执行性能：分层编译、内联与去虚拟化
.NET Core 3.0之后引入的分层编译机制，让JIT不再追求一次性生成高度优化的代码。方法首次调用时，JIT会快速生成低质量但启动快的代码，随后在后台用更高优化级别重新编译热点方法并替换。这种设计平衡了启动时间与长期运行吞吐量。在.NET 8及后续版本中，分层编译默认开启，还会根据方法调用次数和循环热度动态升级优化等级。
JIT的优化手段包括内联、边界检查消除、循环展开、常量折叠和去虚拟化。以方法内联为例，当一个private或sealed方法体积足够小且调用频率高时，JIT会直接将被调用方法的代码嵌入调用者中，省去call指令和参数传递开销。下面的代码在Release模式下几乎必然被内联：
private static int Square(int x)
{
return x * x;
}
public static int SumSquares(int a, int b)
{
return Square(a) + Square(b);
}
运行时JIT可能将Square直接替换为乘法操作，甚至把多个操作合并。边界检查消除则针对数组和字符串索引操作。如果JIT能够证明索引变量始终在合法范围内，就会省略检查指令，这对于循环内数组访问的性能提升非常明显。去虚拟化则是当JIT确认虚方法调用的实际接收者类型唯一时，将虚调用改为直接调用，为进一步内联创造条件。
性能排查通常借助BenchmarkDotNet、PerfView或dotnet-trace。BenchmarkDotNet可以测量方法级别的开销，PerfView能看到JIT事件、GC停顿和CPU采样。查看JIT生成结果可以通过设置DOTNET_JitDisasm环境变量，或者在Visual Studio中启用反汇编窗口。需要注意的是，Debug配置下JIT几乎不做优化，所有变量都保留栈槽位，而Release配置的代码可能与源码结构差异巨大，不能仅凭源码行号判断性能热点。
四、从JIT到AOT：NativeAOT与跨平台执行差异
JIT模式适合长时间运行的服务端程序，因为它可以针对实际运行的CPU生成指令，并根据运行时数据做投机优化。但对于启动时间敏感的命令行工具、无服务器函数或客户端应用，JIT的首次编译延迟会带来明显负担。NativeAOT通过编译期把IL直接生成本机代码，生成的可执行文件不再依赖JIT，也减小了发布体积。不过NativeAOT对动态反射、动态加载程序集和运行时代码生成的限制较多，需要开发者显式声明反射使用的类型。
除了NativeAOT，.NET还提供ReadyToRun和单文件发布等折中方案。ReadyToRun在构建时预编译大部分方法，但仍保留IL与JIT能力，适合容器镜像分发。单文件发布则把程序集和运行时依赖打包到一个可执行文件中，不改变JIT执行模型。不同平台上的JIT实现也有差异：Windows下使用RyuJIT，ARM64平台有自己的指令选择策略，Linux与macOS上的代码质量与Windows基本一致，但某些硬件加速指令的启用条件可能不同。
查看IL与程序集结构仍然是排查底层问题的有效手段。ILSpy支持将程序集反编译为C#或IL，dnSpy还能调试并修改IL。对于需要保护知识产权的场景，理解IL有助于评估混淆器和字符串加密的有效性。混淆器通常会重命名元数据、插入控制流混淆指令，但最终仍要生成IL让CLR执行。只要知道如何定位方法体和元数据表，仍然可以还原大部分业务逻辑。
从源码到IL，再从IL到机器码，这条链路涵盖了编译原理、运行时设计、垃圾回收和性能优化。掌握CLR如何解析程序集、JIT如何翻译指令以及AOT如何绕过JIT，能够帮助开发者在日常编码之外建立更完整的系统视图。当遇到启动延迟、反射失败或反编译保护需求时，这些底层知识会快速转化为有效的排查手段。