在 .NET（包括 .NET Core / .NET 5+ / .NET 6 / .NET 7 / .NET 8 等现代版本）生态中，代码从源代码到最终运行时机器码的路径，存在几种不同编译策略，其中 JIT（Just-In-Time）即时编译 和 AOT（Ahead-Of-Time）预编译 / 原生 AOT 是两大典型方式。了解它们的机制、优劣与适用场景，对于优化启动时间、运行性能以及部署方式非常关键。
以下内容将系统地介绍这两种技术，在 .NET 环境下的实践细节，以及选型建议。
基础概念与工作流程
JIT — 即时编译
在 JIT 模型下，.NET 程序在构建阶段首先被编译为 中间语言（IL / CIL），带有元数据与中间指令，同时保留类型、方法、元数据等信息。运行时，当某个方法（或类型、代码路径）第一次被调用时，运行时（CLR / CoreCLR）会触发 JIT 编译器，将相应的 IL 转换成本地机器码（native code），然后执行。后续再次调用时便直接执行本地代码，而不再重复编译。
JIT 编译可以基于当前运行环境（CPU 架构、硬件特征、运行时状态、内存状况等）做优化，甚至根据运行时数据进行一些动态优化（例如内联、分支预测、代码特化等）。
AOT — 预编译 / 原生 AOT
在 AOT 模型下，程序的 IL（以及相关依赖）在发布／构建阶段就被编译成本地机器码（或与本地机器码密切相关的映像形式），生成最终可执行文件或映像。这样在运行阶段，就不需要或尽可能少依赖 JIT 编译，从而节省启动时的 JIT 开销。
在 .NET 的生态里，AOT 形式包括 ReadyToRun（R2R）、Native AOT（又称 “完全 AOT” 或 “原生 AOT”）等变体。ReadyToRun 是一种混合方式：部分 IL 被预编译为本地代码，其余在运行时仍可能 JIT。Native AOT 则力求将程序完整或尽可能多地转为原生机器码，从而降低或消除运行时 JIT 的需求。
.NET 中 JIT 与 AOT 的实现细节与演进
.NET 中的 JIT
在 .NET Core / .NET 中，默认的执行模型就是基于 JIT 的。CLR / CoreCLR 含有 JIT 编译器，负责在程序运行期间将 IL 编译为对应平台的机器码。随着 .NET 版本不断迭代，JIT 编译器也在演进：在新版本中，编译器在内联、循环优化、寄存器分配、代码布局、逃逸分析、循环变换、分支预测等方面均有所改进。
举例来说，在 .NET 10 中，JIT 的代码生成性能有若干新优化，如对结构体参数的寄存器提升 (promotion)、更优的循环逆置 (loop inversion)、更合理的代码布局方法、对数组接口方法的去虚拟化 (devirtualization) 等等。
通过不断改进 JIT 优化策略，.NET 平台力图缩短启动时部分的编译开销，同时在长时间运行时拿到较高的执行性能。
.NET 中的 AOT（Native AOT / ReadyToRun）
.NET 在多个版本中引入了 AOT 或预编译支持，逐渐从混合模式走向更彻底的原生 AOT。
- ReadyToRun（R2R / R2R Images）：这是 .NET 提供的一种中介折中方案。发布时可以为部分 IL 生成预编译本地代码并嵌入映像。运行时如果对某些方法没有预编译，则仍由 JIT 负责。这样可以在一定程度减少启动时的 JIT 负担。
- Native AOT：在 .NET 7 / .NET 8 中，Native AOT 支持更加成熟。通过在项目中设置 <PublishAot>true</PublishAot>，在 dotnet publish 阶段将整个应用编译为本地可执行文件。这个执行文件包含最少的运行时、元数据和依赖组件，不再依赖完整的 CLR JIT 编译。运行时开销更低，启动速度更快。需要注意的是，Native AOT 在某些功能（如反射、代码生成、热加载、动态加载程序集等）上可能有所限制或要求专门配置。并且生成的可执行文件是平台特定的，因此要针对各目标平台分别构建。
- 混合策略：在实际项目中，也可采用混合方式：开发阶段仍使用 JIT 编译以便快速调试与热重载，发布阶段使用 AOT 或 R2R。这样在生产环境下取得更好的启动性能，同时在开发时保留灵活性。
JIT 与 AOT 的优点与局限对比
下面我们从多个维度对比 JIT 与 AOT 在 .NET 环境下的表现与折中。
启动时间 / 冷启动开销
AOT 优势明显
因为大多数或全部方法在发布阶段已经被编译为本地代码，运行时无需或者只需极少 JIT，因此启动时的编译延迟大为减少。对于对启动时间敏感的应用（比如命令行工具、短生命周期服务、Serverless / 函数计算、桌面应用、首次访问 API 等），AOT 带来了显著优势。
JIT 存在启动延迟
对于新方法首次调用时，JIT 需要将 IL 编译为本地代码，这会引入额外延迟。如果应用启动时需要调用许多不同方法，或者依赖路径较长，启动开销可能较大。
长期执行性能与动态优化能力
JIT 更灵活、更能利用运行时信息
JIT 编译器可以采集运行时代码执行信息、上下文分支概率、热路径统计、类型特化等，从而对频繁执行的代码进行进一步优化（如内联扩展、去除冗余代码、循环优化、分支预测等）。对于长期运行的服务或程序，这种动态优化优势显著。
AOT 在某些情况下难以预测优化
由于 AOT 在构建时做优化，无法获得运行时实际的热路径信息，因而在最优性上可能略逊于 JIT 在长时间运行环境中的表现。但现代 AOT 编译器也可能采用 Profile-Guided Optimization （PGO）、分析策略等方式来提升最终生成代码的质量，从而缩小与 JIT 的差距。
可用特性与兼容性
JIT 在动态特性与反射支持方面更灵活
许多动态语言特性、运行时代码生成 (Reflection.Emit)、动态代理 (DynamicProxy)、即时解析等都依赖运行时 JIT。对于这类场景，纯 AOT 有可能不完全支持，或者需要额外配置（例如显式保留、linking、反射元数据注入等）。
AOT 会带来限制或额外注意点
由于编译期需要解决许多动态行为，AOT 对某些库或框架的兼容性可能更受限制。使用 AOT 时可能需要额外指令告诉编译器保留某些类型、方法、反射访问路径等，否则在运行时可能发生缺失或错误。另外，AOT 可执行文件是平台特定的，不能跨平台运行。
二进制大小与部署
AOT 可执行文件通常更大
因为它包含本地代码、必要的运行时组件、元数据保留等内容，故可执行文件体积可能明显大于仅存 IL 的版本。
JIT 部署更灵活 / 小体积
部署时只需包含 IL 程序、运行时库等，通常文件体积较小。对于跨平台、轻量化部署场景更具灵活性。
构建时间与开发效率
AOT 构建时间更长
在发布阶段编译整个程序成本较高，尤其程序规模大时，这部分编译时间可能成为瓶颈。
JIT 在开发阶段更高效
因为不需要大量预编译工作，反复迭代、快速调试、即时编译更为便利。
在 .NET 中的典型使用场景与选型建议
根据不同类型的应用和业务需求，可参考以下选型指南：
选择 JIT 的场景
- 长时间运行的服务 / 后端程序：启动开销相对较不敏感，更看重长期性能优化与稳定性。
- 高度依赖反射、动态代码生成、插件机制等应用：JIT 对这些动态特性支持更自然、兼容性更好。
- 开发 / 调试阶段：JIT 灵活便捷，不用每次都编译 AOT，可以快速测试和调试代码。
- 应用对跨平台支持要求高：JIT 模型下同一个 IL 程序可以在多个平台运行，无需为每个平台单独编译。
选择 AOT（或混合） 的场景
- 启动性能极为关键的应用（首次请求、命令行工具、函数计算、冷启动敏感服务等）。
- 用户体验环境下的客户端应用（桌面、控制台、小型工具等），希望尽快响应。
- 部署环境更可控、平台较固定、运行时开销严格受限的场景。
- 想要减小对完整运行时的依赖，让可执行文件更独立、部署更简单。
- 在实际工程中，许多项目采取折中方案：开发与调试阶段使用 JIT，而发布阶段使用 AOT 或 R2R，以兼顾性能与灵活性。
实践注意事项与优化建议
当你在 .NET 项目中使用或切换 JIT / AOT 时，以下是一些需要注意并优化的点：
- 在使用 Native AOT 时，仔细处理反射、动态加载、泛型、未直接引用的类型／方法保留策略，避免运行时因缺失类型而崩溃。
- 使用 Profile-Guided Optimization (PGO) 或运行时分析结果指导 AOT 编译，以更好地聚焦热点路径优化。
- 对大型项目，可采用模块化、按需编译、拆分程序集策略，减少 AOT 编译负担。
- 在发布时保留诊断符号 (PDB) 或映射表 (mapping)，以便调试或追踪报错时可映射回源代码。
- 对比并监控 JIT 与 AOT 版本在启动时间、长期运行性能、内存使用、二进制大小等指标，进行权衡分析。
- 在不断演进的 .NET 平台版本中，关注 JIT 编译器与 AOT 支持方面的新特性，因为 .NET 团队持续在这两方面推进优化。
在 .NET Core / 现代 .NET 平台中，JIT 与 AOT 各有优劣：JIT 提供了灵活性、动态优化能力和开发便捷性；AOT 在启动性能和部署简洁性上具有明显优势。合理掌握它们的原理与局限，并根据具体应用场景做出折中与选择，是构建高效、响应快的 .NET 应用的重要基础。