CLR 加载 IL 后不会立刻编译，而是延迟到方法首次调用时才触发 JIT
这是 JIT 的核心机制：不是整个程序启动时一并编译，而是一个方法一个方法地“按需编译”。
mscorlib.dll或你自己的
MyApp.dll被加载进进程后，其中的 IL（中间语言）只是被验证和元数据解析，真正生成本地机器码发生在第一次执行某个方法时。
比如调用
Console.WriteLine()，CLR 会检查该方法是否已被编译；若没有，就触发 JIT 编译器对这个方法的 IL 块做一次翻译，生成 x64 或 ARM64 指令，并缓存到内存中。后续再调用它就直接跳转到已编译的本地代码，跳过编译开销。 JIT 编译是线程安全的，多个线程同时首次调用同一方法，只会有一个线程真正执行编译，其余等待 编译结果只在当前 AppDomain（.NET Framework）或 AssemblyLoadContext（.NET Core/5+）内有效，跨上下文不共享 方法内联、循环展开等优化由 JIT 在运行时决定，取决于当前 CPU 架构和运行时配置（如
DOTNET_JIT_OPTIMIZATIONTier）
不同 .NET 版本的 JIT 引擎差异明显，特别是 Tiered Compilation 的引入
.NET Core 3.0 起默认启用分层编译（Tiered Compilation），它让 JIT 不再“一次编译、终身使用”，而是分两级：
Tier 0：快速生成低优化度代码（几乎无内联、无循环优化），目标是降低启动延迟；方法被调用几次后触发重编译 Tier 1：完整优化编译（启用所有 JIT 优化策略），替换掉 Tier 0 的代码；触发条件通常是方法被热路径执行（如循环体、高频 API）你可以用环境变量临时关闭它来观察行为差异：
DOTNET_TieredCompilation=0。关闭后所有方法都走 Tier 1 流程，启动慢但稳态性能略高；开启后冷启动快，且长期运行下热点方法仍能获得最佳性能。
注意：.NET Native（UWP）和 AOT 编译（如
dotnet publish -r win-x64 --aot）完全绕过 JIT，IL 在构建时就被编译为原生代码，此时
System.Runtime.CompilerServices.JitHelpers等类型不可用。
JIT 编译失败时常见错误是 MethodImplOptions.AggressiveOptimization 或泛型约束引发的验证失败
不是所有 IL 都能被 JIT 接受。典型失败场景包括：
在AggressiveOptimization方法里用了不支持的 IL 指令（如某些未验证的指针操作），JIT 会拒绝编译并抛出
NotSupportedException泛型方法含复杂约束（如
where T : new(), IComparable<t>, IDisposable</t>）且实例化时类型不满足全部约束，可能在 JIT 时才发现——错误信息常是
InvalidProgramException或
VerificationException（.NET Framework） 调试模式下启用了
DebuggableAttribute.DebuggingModes.DisableOptimizations，可能导致某些优化路径失效，间接影响 JIT 行为
这类问题往往只在 Release 模式、特定 CPU 架构（如 ARM64）、或 Tier 1 编译阶段暴露，开发阶段不易复现。建议用
dotnet trace或 PerfView 抓取 JIT 日志（启用
Microsoft-Windows-DotNETRuntime/JIT/MethodJittedVerbose事件）定位具体哪个方法卡住。
想看 JIT 实际干了什么？用 COMPLUS_JitDisasm
或 dotnet-dump
查看生成的汇编
最直接的方式是让 JIT 输出汇编指令。例如，在 Windows 上设置环境变量后运行程序：
set COMPLUS_JitDisasm=MyNamespace.MyClass::MyMethod dotnet run
控制台就会打印出该方法经 JIT 编译后的 x64 汇编（含寄存器分配、指令选择细节）。注意它只对首次调用生效，且仅限当前进程。
更通用的做法是用
dotnet-dump分析运行中进程： 先
dotnet-dump collect -p <pid></pid>保存内存快照 再
dotnet-dump analyze <dumpfile></dumpfile>，然后输入
clrstack -a找到目标线程和方法地址 最后用
dumpil <methodaddr></methodaddr>看 IL，
dumpmt -md <methodaddr></methodaddr>查 JIT 状态，
u <nativeaddr></nativeaddr>反汇编本地代码
这些输出里能看到 JIT 如何把
for (int i = 0; i 优化成无边界检查的循环，或如何把 <code>if (obj is string s)编译成单条
test+
je指令——但前提是没被内联进调用方。
真正难调试的永远不是“JIT 没工作”，而是“它工作得太聪明”：比如把一个看似复杂的判断折叠成常量，或因内联导致堆栈无法映射回原始 C# 行号。这时候得关掉内联（
[MethodImpl(MethodImplOptions.NoInlining)]）再对比。
