当面试官问怎么缩小.NET发布后的文件体积、去掉多余依赖呢？想起了AOT,那么提到AOT首先要了解JIT。 长期以来，大多数 .NET 应用都依赖 即时编译（JIT，Just-In-Time） 机制运行。也就是说，程序发布时是中间语言（IL），真正执行前，再由 JIT 编译器在运行时把 IL 转换成当前平台的机器码。
这种模式的好处很明显：JIT 可以根据实际运行环境做针对性的优化，理论上"越跑越快"。但代价同样清晰------启动慢、内存占用高。在应用规模较小时问题不大，一旦进入云原生、Serverless 或高密度容器部署场景，这些问题就会被无限放大①。
正是在这样的背景下，.NET 引入了 预编译（Ahead-of-Time，AOT） 技术，而其中最彻底、也最激进的一种实现方式，就是 Native AOT。
什么是预编译（AOT）？
AOT 的核心思想其实很简单：把编译尽量前移。不再等程序启动后再做 JIT 编译，而是在构建阶段，就把 IL 直接编译成目标平台的原生机器码。
从编译模型上看，.NET 目前主要有三种形态：
-
JIT：运行时编译，启动慢但灵活
-
ReadyToRun（R2R）：构建时进行部分预编译，运行时仍可能回退到 JIT
-
Native AOT：构建时完全编译，不再依赖 JIT①
| 编译模型 | 编译时机 |
|---|---|
| JIT | 运行时 |
| ReadyToRun (R2R) | 构建时部分预编译 |
| Native AOT | 构建时完全编译① |
由于省去了运行时的编译过程，AOT 应用在启动阶段几乎"开箱即用"，这对冷启动敏感的场景尤为关键。
Native AOT 在 .NET 中的定位
Native AOT 的目标非常明确：把一个 .NET 应用，变成真正的原生程序。
在这种模式下，最终产物是一个独立的可执行文件，它不再依赖任何 .NET 运行时组件，也不包含 JIT 编译器。其主要特性包括：
首先是零运行时依赖 。部署环境中无需安装 .NET Runtime，拷贝一个文件即可运行，这在容器和边缘设备场景中非常友好。其次是完全自包含 。应用所需的运行时逻辑、基础库都会被打包进最终二进制文件中，部署和分发极其简单。再者是启动速度极快 。进程启动后几乎可以立刻进入业务逻辑，通常只需数十毫秒。最后是更低的内存占用。没有 JIT 编译缓存，也没有大量运行时元数据，整体内存模型更加紧凑。
正因为这些特性，Native AOT 特别适合以下场景：
微服务与容器化部署； Serverless 函数（如 Azure Functions）； 命令行工具（CLI）； 资源受限的边缘设备①。
Native AOT 的内部工作原理
1. 编译流水线
从整体流程来看，Native AOT 的编译并不是"简单提前编译"，而是一条完整的静态编译流水线。大致过程包括：
IL 代码生成 → 静态分析 → 代码裁剪 → 原生代码生成 → 链接为单一可执行文件。
这一步骤的核心目标只有一个：把运行时可能发生的事情，尽量提前到构建期解决。
2. 代码裁剪（Trimming）与树摇（Tree Shaking）
为了让最终产物足够小、足够干净，Native AOT 会进行非常激进的静态分析。
它会裁剪掉所有"确定不会被使用"的代码，包括：
未被调用的类型、方法和字段；未实际引用的程序集和 NuGet 依赖；运行时无法触达的分支路径。
对于反射这类动态特性，编译器会尝试分析哪些成员可能被访问，并在必要时强制保留。正因如此，Native AOT 对反射的使用有更严格的要求。
这种裁剪策略带来的效果非常直观：
最终体积通常比传统自包含发布小 50% 以上； 内存占用显著下降；攻击面随代码量减少而同步降低①。
性能优势
1. 启动速度极快
在 Serverless 或 Kubernetes 自动扩缩容场景中，启动时间往往直接影响用户体验和资源成本。
实测数据显示，Native AOT 应用通常可以在 10--50 毫秒 内完成启动，而传统 JIT 应用往往需要 300--2000 毫秒①。这种差距，在冷启动频繁的系统中尤为致命。
2. 更低的内存开销
Native AOT 的内存优势主要来自几个方面：
不再需要 JIT 编译器常驻内存；GC 堆更小，未使用对象在构建期已被裁剪；运行时元数据大幅减少。这使得 Native AOT 特别适合高密度部署场景。
3. 更可预测的运行性能
JIT 编译虽然灵活，但也意味着：在运行过程中，可能会因为编译而短暂停顿。
Native AOT 完全消除了这一不确定性。所有代码在构建期就已确定，执行路径清晰稳定，不会出现"某次请求突然变慢"的 JIT 抖动问题①。
结语
Native AOT 并不是要取代 JIT，而是为 .NET 提供了一种面向现代部署环境的新选择。它牺牲了一部分动态能力（例如反射、运行时代码生成），换来了启动速度、内存效率和部署体验上的巨大提升。
在微服务、Serverless、CLI 工具等场景中，使用AOT是值得的。随着 .NET 8 及后续版本对 AOT 支持的持续增强，Native AOT 正在从"少数人使用的高级选项"，逐步走向更广泛的主流应用场景①。
Native AOT怎么处理反射的问题呢？大家对Native AOT 有什么看法？欢迎留言讨论。
① 内容综合参考自 Microsoft 官方文档：
-
.NET Native AOT Overview（https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/）