构建一个教学级 C# AOT 编译器从 IL 到 C 的完整技术地图0. 前言为什么你需要了解 AOT 的全景.NET 的 AOTAhead-of-Time编译不仅仅是一个“把 IL 变成机器码”的翻译器。从开源的 CoreRT 到产品化的 NativeAOT一套工业可用的 AOT 工具链需要同时解决代码生成、依赖分析、垃圾回收交互、异常处理、反射静态化、泛型膨胀控制、互操作、线程模型以及运行时接线的数十个工程难题。这些难题每一个都足以成为独立的课题而把它们缝合为一个可工作的系统的“端到端E2E接线”能力更是从玩具到产品的分水岭。本文无意实现一个生产级编译器而是以教学为目的勾勒出一张覆盖全部关键点的技术地图。我们会沿着一条简化的 AOT 编译管线逐一探讨下列主题依赖分析与树摇裁剪、泛型共享与代码膨胀管理、去虚拟化与内联、反射与元数据处理、代码生成栈压低、InternalCall 的端到端接线、精确 GC 与帧根优化、异常管理与栈展开、调用堆栈生成、互操作与线程支持、启动与内存优化字符串池、内存池、碎片整理以及常被忽略的折叠、压缩与跟踪。全文的核心思想是在每一个技术点上我们都会给出“教学版可以怎么做”的极简实现思路并同时点明工业界为此付出的真实工程代价。对于每个模块我们还会标注其实现难度⭐⭐⭐⭐⭐⭐以便读者制定学习路线。读完本文后你将能理解 .NET NativeAOT 这类框架为什么会有那么多限制也会知道如果想自己从零写一个 AOT 编译器每一步该往哪个方向走。1. 系统总览编译管线与运行时库一个完整的 AOT 编译器由两部分构成编译时工具链ILC和运行时支持库。编译时工具链的输入是已由 C# 编译器Roslyn生成的托管程序集输出是包含原生机器码、EEType 表、泛型字典、元数据块和异常表的对象文件随后通过平台链接器生成单个可执行文件。它的工作流程大致为[.NET DLLs] → 依赖图构建与裁剪 → 泛型实例化决策 → 去虚拟化/内联 → IL到机器码翻译 → 生成数据节与元数据 → 链接 → [Native Exe]教学版编译器为降低复杂度通常会把“IL 到机器码”这一步替换为“IL 到 C 源码”的转译再利用普通 C 编译器完成最终编译。这样能绕过寄存器分配和指令选择的细枝末节把精力集中在 AOT 独有的系统问题上。即便如此我们仍然需要设计一个与之配合的极简运行时库负责对象分配、GC 接口、类型系统基座和异常投递。推荐工具链使用Mono.Cecil解析程序集自行编写依赖分析器和 C 代码生成器运行时库以少量 C 文件提供最后用clang或平台对应的 C 编译器将生成的源码与运行时库链接为可执行文件。2. 依赖分析与树摇裁剪 ⭐⭐⭐⭐⭐⭐2.1 问题描述托管程序集包含程序引用的所有方法、类型和字段但实际运行中可能只有一小部分被用到。JIT 模式按需编译天然具备“软裁剪”能力AOT 则必须在编译期以不可恢复的方式删除无用代码否则镜像尺寸会失控。2.2 核心机制根集合 可达性图AOT 编译器会从一个根集合出发通过静态调用图、类型继承关系和反射指令分析递归地标记所有可达的代码和数据节点。根集合通常包括程序集入口点、显式导出的方法、反射保留指令rd.xml 或注解、Interop 与 P/Invoke 桩。编译器以方法、类型、EEType、接口映射等为节点以“调用”、“继承”、“类型使用”、“反射可见”等为有向边构建一张依赖图。从根开始遍历未被标记的节点就被视作“死代码”并丢弃。教学版实现可用Mono.Cecil手工实现递归的 Mark-and-Sweep先标记所有根遍历 IL 指令遇到call、newobj、ldtoken等递归标记被引用成员。虚调用保守标记所有可能重写反射要求显式声明保留如keep.xml。2.3 库边界与框架依赖的裁剪困境 ⭐⭐⭐⭐教学版通常只处理单个程序集或极少的依赖因此依赖分析看似简单。但在工业环境下一个实际应用往往引用数十个甚至上百个系统库如System.Collections、System.Linq、System.Net.Http而不可能把整个 .NET 框架库全编译进镜像。ILC 必须精确判断一个库的哪些类型和方法因为应用的实际调用而被需要库与库之间的依赖如何传递例如System.Linq.Enumerable.Select内部使用了System.Collections.Generic.IEnumerableT只需裁剪出这两个具体相关的最小集合而不是拉入整个System.Linq和System.Collections。反射依赖往往隐藏很深一个类型名称字符串可能导致一整个继承链被拉入。工业级工具依赖反射扫描器自动识别这些模式并生成最小化的元数据但判定“多少才够”极其困难——漏掉一个运行时就会抛出MissingMetadataException多保留镜像就无谓膨胀。更复杂的是某些依赖只有在特定平台或配置下才生效条件编译、平台特定实现编译器必须了解这些上下文。教学版完全忽略这些边界手工裁剪几个程序集工业级则需要维护庞大的元数据标注如DynamicallyAccessedMembers特性和复杂的图算法才能接近理想镜像尺寸。3. 泛型共享与代码膨胀管理 ⭐⭐⭐3.1 问题的起源C# 泛型在 IL 层面是完整保留的例如Listint和Liststring是两个不同的实例化拥有自己独立的 EEType 和可能独立的 JIT 代码。AOT 编译如果为每一个可能的实例化都生成一份专用机器码会造成严重的代码膨胀特别是引用类型参数如Listobject、ListStream等在运行时行为完全一致它们的代码完全可以共享。3.2 共享策略canonical 代码 泛型字典工业 AOT 的做法是将引用类型参数的泛型实例化统一“规范化”canonicalization。例如所有Listobject、Liststring、ListMyClass共享同一份规范化代码而代码中访问泛型上下文的部分如对T类型的操作则通过一个隐藏的泛型字典参数来间接获取。字典中存放了实际类型的 EEType 指针、方法入口、接口实现等信息。值类型实例化Listint等因为内联需求和内存布局差异则仍然保留专用代码。在实现中泛型字典的布局由DictionaryLayout描述槽位索引在编译期确定。工业系统NativeAOT还支持惰性字典扩展——编译期只分配部分槽位运行时 TypeLoader 可以按需补充从而在镜像大小和动态性之间取得平衡。3.3 教学版泛型处理教学版编译器可以采取一个中间策略有限值类型实例化 引用类型全部共享。具体来说在依赖分析阶段收集所有实际出现的值类型实例化如Listint、Nullabledouble为它们生成专用代码对于所有引用类型实例化只编译一份 canonical 版本并在调用点传入一个运行时构造的字典。字典的实现可以很简单在 C 端每个泛型类对应一个DictionaryLayout的静态数组槽位索引在编译期确定运行期只需通过指针加偏移读取。例如ListT.Add(T item)的字典可能包含T的 EEType 指针用于类型检查或default(T)的初始化。教学版可以不处理惰性扩展整个字典在编译期静态分配即可。这样代码量从O(引用类型实例化数)降为O(1)显著减轻镜像膨胀。教学中可以清楚地看到一个小小的字典参数如何解决了代码共享问题。4. 去虚拟化与内联 ⭐⭐⭐⭐4.1 去虚拟化虚方法调用callvirt在运行时需要通过 vtable 或接口分派表间接跳转开销较大且阻止内联。AOT 编译时的去虚拟化Devirtualization旨在将那些可以静态证明其目标的虚调用转为直接调用。对于sealed 类、sealed 方法或者类型不可继承的情况编译器可以安全地去掉间接层。进一步如果编译器能进行全局可见性分析证明某个类在程序内不可能再有子类也可以将其视为有效密封effectively sealed。教学版编译器可以做一个简单的去虚拟化在依赖图遍历时如果发现某个虚调用的this类型是 sealed或者调用解析结果在闭包内只有一个可能的重写就直接把callvirt替换为call。更复杂的整程序分析如对public类的保守判定可以省略直接保留虚调用即可。4.2 内联内联通常由后端完成但在 AOT 中去虚拟化给内联创造了极大的机会——一旦虚调用变成直接调用内联器就可以看穿函数体把代码合并到调用者中进而消除调用开销产生更大的优化窗口。教学版如果采用 C 转译最简单的“内联”就是直接在生成 C 时把被调用函数体展开但这会破坏代码结构。一个更清晰的做法是依赖 C 编译器的优化能力如果我们把去虚拟化后的方法声明为inline并在同一个编译单元中生成C 编译器自然会完成内联。真正涉及跨函数边界的 IR 合并可以留作高阶练习。5. 反射与元数据静态化动态能力 ⭐⭐⭐反射是 .NET 的重要特性但它依赖完整的元数据类型名、成员签名、属性等。AOT 编译默认只保留代码元数据被大量剥离。为了让反射可用必须提前决定“哪些反射操作需要在运行时工作”并把相应元数据嵌入镜像。教学版编译器可以简单要求使用者提供一个配置文件类似rd.xml明确列出所有需要反射支持的类型和成员。编译器将这些类型和成员的类型信息结构体、名称字符串、签名 blob生成到 C 全局数据区并注册到一张反射表中。运行时的Type.GetType()和MethodInfo.Invoke()则通过这张表查找。对于“按名称查找”的需求字符串和签名的存储本身会占据较大空间这涉及到元数据压缩与折叠。工业上会使用二进制格式如 NativeLayout并去除调试信息教学版则可以直接用 C 的字符串常量并利用链接器的字符串合并能力来减少重复。反射的另一大负担是“动态实例化泛型”和“动态方法调用”。这超出了静态 AOT 的范围大多数教学实现会直接将其列为不支持。如需支持必须引入运行时的 TypeLoader 和按需 EEType 生成机制这是一个高难度模块⭐⭐⭐⭐。6. 代码生成从栈式 IL 到 C 的两种路径 ⭐⭐⭐⭐⭐即使已经完成了依赖裁剪和高级优化最终仍然需要把 IL 翻译成 C 或机器码。教学语境下有两种流行路径路径 A解释器固化模式每条 IL 指令直译为对std::vectorRuntimeValue的操作控制流用goto实现。这相当于把解释器固化在了源码中实现极其简单但不产生任何优化效果运行时性能低。路径 B栈压低Stack Lowering通过分析 IL 的栈行为将每个临时的栈槽映射到 C 局部变量。例如ldarg.0→int32_t tmp0 a;add→int32_t tmp1 tmp0 tmp1;。这需要遍历指令并维护一个符号化的栈深度为每一层栈槽分配临时变量名。之后可以删除冗余赋值进行简单常量折叠。路径 B 生成的代码更接近人类编写也更容易被 C 编译器优化。本文推荐采用路径 B 作为教学进阶版它的核心是一个单遍的栈模拟只不过将模拟结果“记录”为变量。同时我们可以顺手实现一些基本优化如常量折叠ldc.i4 3; ldc.i4 5; add直接生成8和无用指令裁剪对从未读取的局部变量不再生成赋值。7. E2E 接线编译代码如何与运行时库对话 ⭐⭐⭐⭐⭐⭐⭐⭐⭐这是经常被新手忽视、但工业上最核心的难点之一。编译出来的 C 函数并不能独立存在它需要调用运行时库提供的服务——分配对象、写屏障、类型检查、抛出异常等。这些服务在 JIT 中是 VM 直接提供的AOT 则需要通过稳定的符号接口进行连接。7.1 InternalCall 的直接映射托管代码中大量核心功能是以internalcall方式在 CLR 内部实现的例如对象分配、类型检查、字符串操作、线程同步、数学函数等。AOT 编译器必须为每个这样的调用点生成对运行时正确函数的调用。7.2 内部调用的数量与正确性挑战完整的 .NET CLR 内部调用函数数量极为庞大——接近两千个。这包含最基础的System.Object.GetType()、System.String.FastAllocateString()到复杂的System.Threading.Monitor.Enter()、System.GC.Collect()等。在教学版中我们可以只实现几个关键的如new、cast来跑通简单示例。但工业级 AOT 编译器必须逐一切实实现这些函数并且不能出错因为生成的代码会直接调用它们任何签名不匹配、语义偏差或线程安全问题都会导致程序崩溃或未定义行为。教学版可以完全回避这一难题——将internalcall替换为简单的 C 模拟例如Thread.Sleep直接调用std::this_thread::sleep_for。但工业级实现需要为每一个内部调用提供等价的 C 实现确保与 JIT 模式下 CLR 的行为一致。处理平台差异Windows/Linux/macOS 的线程原语、文件系统 API 等完全不同。维护这些实现与 .NET 版本同步——.NET 每版都会增加或修改内部调用AOT 运行时库必须跟随更新。正是这近两千个内部调用的精确实现构成了工业 AOT 运行时库的主体工作之一也是看似“重复造轮子”却无法避免的浩大工程。7.3 GC 写屏障托管堆中引用类型字段的写入必须通过写屏障通知 GC。例如obj-field other会被转译为__runtime_assign_ref(obj-field, other);。该写屏障内部会更新卡片标记并可能触发 GC。教学版可以使用简单的引用计数作为 GC 替代此时写屏障只需处理引用计数的增减。但如果要模拟精确 GC就必须在每次写引用时插入写屏障这是 E2E 接线中的典型例子。7.4 互操作与线程支持P/Invoke 调用、委托封送以及线程模型是 AOT 的另一大接线战场。教学版可将 P/Invoke 简单映射为extern声明ThreadStatic字段用 C11 的thread_local模拟lock语句用std::mutex替代。工业级则需处理封送 thunk、委托回调、ABI 转换等每一项都极为繁重。8. 精确 GC 与帧根优化 ⭐⭐⭐⭐要支持 GC就必须让 GC 能够找到所有正在使用中的托管引用——这些引用可能位于寄存器、栈帧或静态变量中。JIT 编译时会生成“GC 信息”来描述每个安全点处哪些位置有根。AOT 编译器同样需要生成这些信息否则 GC 会误回收仍在使用的对象或留下悬空引用。8.1 教学版的“显式帧根”方案最简化的精确 GC 方案是在编译时为每个函数生成一个__gc_roots数组包含所有栈上对象的指针的指针。在每次可能触发 GC 的调用如分配对象前更新这些指针GC 扫描时直接遍历这个根数组。这种主动注册根地址的方式称为显式帧根它不同于“保守式栈扫描”后者是把整个栈当作指针来推测是精确 GC 的一种简化教学实现。例如一个函数voidMyFunc(){Object*a__runtime_new_object(...);Object*b__runtime_new_object(...);}可以被转译为voidMyFunc(){Object*anullptr,*bnullptr;FrameRoots __roots{a,b};__runtime_push_frame(__roots);a__runtime_new_object(...);b__runtime_new_object(...);__runtime_pop_frame();}这样 GC 在发生时只要遍历当前线程的所有帧根链表就能找到所有活动引用。需要留意的是若编译器删除了“已无用”的变量赋值但该变量的地址仍在帧根数组中GC 会看到一个过期值可能造成对象被错误保留。工业系统通过精确的 GC 信息编码和活跃变量分析避免此问题。8.2 帧根优化所谓“帧根优化”就是减少需要报告的根的数量。例如如果某个局部变量在某个调用之后不再使用那么在该调用之后的安全点它可以被排除出根集合。这需要活跃变量分析教学版可以选择不做或手动在 IL 层识别。9. 调用堆栈与异常管理 ⭐⭐⭐9.1 调用堆栈为了在异常发生或调试时能输出托管堆栈追踪每个托管函数调用都需要在进入时注册一个“栈帧”到线程本地链表。帧中包含了调用者的返回地址和方法标识。简单实现可以在每个转译后的函数开头加入类似__runtime_push_frame(EETypePtr, __frame)的代码函数返回前弹出。这里的push_frame指的是向调用堆栈注册一个新帧与上一节 GC 的帧根报告根地址是两套机制应在命名或文档中明确区分。9.2 异常处理托管异常处理远比throw/catch复杂它要求支持catch的类型过滤和finally的保证执行。完整实现需要生成平台特定的展开表如 Windows SEH、Linux DWARF。这难度极大教学编译器可以通过编译期展开来回避将try-catch-finally结构在 IL 层面直接转换为带有跳转判断的goto代码。但要注意finally块的保证执行要求每个return、break、甚至异常出口都必须先执行finally块。实现时需要在每个可能的出口前复制或跳转到finally代码这增加了代码生成的复杂度。若catch块缺失则直接调用abort()。工业编译器如 CoreRT则将 IL 的异常处理子句翻译为展开表由运行时统一调度。这也是其移植性难度大的原因之一。10. 内存管理与优化字符串池、内存池、碎片整理、折叠与跟踪 ⭐⭐⭐⭐⭐⭐⭐除了代码生成运行时内存管理是工业 AOT 的另一大支柱。教学版通常直接调用 C 的new/delete或malloc完全依赖系统堆忽略托管内存的固有需求。而工业级 AOT 必须在以下方面做深度优化10.1 字符串池托管代码中大量使用字符串字面量。JIT 模式将字面量“内化”intern到运行时字符串表重复字符串共享同一份内存。AOT 编译时必须预生成这个字符串池编译期收集所有ldstr引用的字面量在镜像数据段中分配只读字符串对象全局唯一。运行时String.Intern直接从该池查找。这不仅能节省内存还能加速字符串相等比较引用相等。工业实现还需处理动态生成的字符串如StringBuilder结果是否需要入池的复杂策略。10.2 内存池与对象分配频繁的小对象分配如new object()、临时数组直接调用系统堆会使性能大幅下降。工业 GC 使用代际generational管理并预分配内存池heap segments。AOT 编译产物与 GC 深度集成分配辅助函数RhpNewObject不仅从 GC 堆的分配上下文中快速指针搬运bump-pointer还需在 GC 发生时配合压缩/移动。此外静态分析可为某些类型预先保留内存池或使用“冻结段”将已知生命期对象置入只读内存。10.3 内存碎片整理与对象移动托管堆在长期运行中会产生内存碎片。工业 GC 通过压缩compaction阶段移动存活对象合并空闲块。这就要求 AOT 编译器生成精确的GC 信息不仅报告哪些位置有根引用还要报告引用的基地址和位置以便 GC 移动对象后更新所有指向它的指针。生成的 C 代码若直接使用原始指针Object*在移动式 GC 下将全部失效——工业方案中AOT 代码或使用手柄handles或配合 GC 在安全点暂停并批量修正指针。教学版完全避开此问题通常使用不可移动的引用计数或保守 GC。10.4 折叠、压缩与 PGO常量折叠与删除编译期计算常量表达式。元数据压缩类型名、签名字符串合并到全局表去重。PGO跟踪利用运行时反馈优化去虚拟化和内联决策。11. 一张全景表教学版做了什么没做什么技术点难度教学版实现工业级补充依赖分析/裁剪⭐⭐⭐⭐⭐⭐手工标记递归遍历反射需手工配置保留自动反射扫描、库边界依赖传递、按需类型生成、接口分析泛型共享⭐⭐⭐引用类型 canonical 简单字典值类型预实例化惰性字典扩展、UniversalCanon去虚拟化⭐⭐仅对 sealed 类生效全程序可见性分析、有效密封推断内联⭐⭐依赖 C 编译器或简单展开跨程序集内联、PGO 决策代码生成⭐⭐⭐⭐⭐IL 栈压低为局部变量简单常量折叠寄存器分配、向量化、深度内联反射与元数据⭐⭐⭐手动配置保留编译期生成查找表无动态生成反射扫描器、NativeLayout、按名重建内部调用实现⭐⭐⭐⭐⭐实现 5~10 个关键 helper其余用 C 近似替代近 2000 个 internalcall 逐个正确实现平台适配E2E 接线⭐⭐⭐⭐硬编码 helper 函数列表手写调用映射全自动符号解析、ABI 适配、GOT/PLT 处理精确 GC⭐⭐⭐⭐显式帧根链表扫描不可移动对象精确 GC 信息编码、寄存器扫描、移动式 GC异常处理⭐⭐⭐编译期展开为goto需小心 finally 保证平台展开表完整 finally 保证调用堆栈⭐⭐手工压入/弹出托管帧与 GC 帧根区分基于展开信息的回溯互操作与线程⭐⭐⭐⭐⭐⭐⭐简单 P/Invoke 映射、thread_local模拟封送 thunk、委托回调、ABI 转换、线程模型集成启动优化⭐⭐手动预初始化构造结果硬编码冻结段、泛型预初始化、启动序列优化字符串池⭐⭐⭐无使用 C 原生字符串字面量或每次动态分配编译期全局字符串池、字面量去重、String.Intern支持内存池⭐⭐⭐⭐直接调用new/malloc无托管分配优化GC 代际堆、bump-pointer 分配、对象池、冻结段碎片整理/移动⭐⭐⭐⭐⭐无移动对象固定不动引用计数或保守 GC压缩式 GC、对象移动、全局指针修正、写屏障增强代码膨胀控制⭐⭐⭐泛型共享 树摇PGO 去虚拟化、轮廓导向内联调试信息⭐⭐可选生成#line指令映射回 C# 源码完整 PDB/DWARF 生成、序列点与内联帧还原12. 端到端最小示例为提供可复现的起点这里给出一个极简的“静态方法加法”转译全流程。C# 输入Add.cs编译为 Add.dllpublicclassCalculator{publicstaticintAdd(inta,intb)ab;}IL 核心片段IL_0000: ldarg.0 IL_0001: ldarg.1 IL_0002: add IL_0003: ret转译器生成的 C 代码基于栈压低路径// 运行时基础定义略#includeruntime.hint32_tCalculator_Add(int32_ta,int32_tb){int32_t__tmp0a;int32_t__tmp1b;int32_t__tmp2__tmp0__tmp1;return__tmp2;}构建命令示意# 1. 用 Roslyn 编译 C# 为 DLLcsc /t:library Add.cs# 2. 运行自制转译器C# 编写读取 DLL生成 C 源码dotnet run--projectMyAotCompiler -- Add.dll output.cpp# 3. 用 C 编译器将生成的源码与运行时库链接clang-oadd_app output.cpp runtime.cpp ./add_app# 自行添加调用代码测试这个示例刻意省略了对象分配、GC、异常等复杂特性仅展示最基础的算术运算转译。扩展它只需逐步增加指令支持、类型系统和运行时 helper 即可。13. 结语从“可用”到“工业级”的距离本文遍历了一个 AOT 编译器所必须面对的方方面面并给出了教学可用的简化方案。如果把这些简化实现逐一拼装我们能够在几周内构建出一个可以编译并运行简单 C# 程序的转译器——它拥有基本的依赖裁剪、泛型共享、简单的去虚拟化、显式的 GC 根和可工作的反射路径。这对于学习编译原理、运行时设计已经足够。然而工业级 AOT 与这个教学版之间的距离就是“可靠性”和“性能”的距离反射分析必须零遗漏、GC 信息必须比特精确、异常处理必须在每个平台上都符合 ABI、泛型字典必须保证线程安全的惰性初始化、启动性能必须优化到毫秒级、互操作封送必须处理所有边界情况……更重要的是内存管理必须提供高效的字符串池、预分配的内存池以及能整理碎片的移动式 GC依赖裁剪必须精确到库与库之间的边界近两千个内部调用必须逐个正确实现。这些都需要编译器、运行时和基础库三方在安全点精确协作对生成代码的每一条指针操作都施加精细的控制。这些问题的解往往不存在巧妙的捷径只有扎实的工程积累、数十万行的基础代码和大量的边界测试。一个值得深思的对比是 IL 解释器。像 ILRuntime 这样的解释器其工作原理是寄生在现有 .NET 运行时之上它通过反射或 Emit 动态调用底层 CLR 的服务对象分配、类型检查、字符串操作等解释器本身只需要处理 IL 的语义调度。若要提升性能只需在调度循环中加入更多静态特化的快速路径比如为常见指令编写case分支而完全不需要触碰运行时的底层实现——不需要自己写 GC不需要实现 InternalCall不需要处理平台 ABI也不需要做依赖裁剪。这正是解释器方案之所以“简单”的根本原因它没有跨出宿主运行时的边界所有复杂的系统服务都由现成的 CLR 提供。而 AOT 编译器的本质恰恰是脱离了这套现成的运行时。一旦你要生成独立可执行的本地代码你就必须自己提供所有运行时服务并且必须保证它们与原来 CLR 的行为语义等价。这份“等价性”的担保就是那近两千个内部调用、精确的 GC 协作、完整的异常展开和元数据重建。ILRuntime 可以借用、可以近似、可以在宿主运行时上搭建桥梁AOT 编译器却必须自建整座桥并让它承受全部流量。认识到这一根本性差异才能理解为什么“简单的 IL 转译器”和“真正的 AOT 编译器”之间隔着的是整个运行时工程的鸿沟。希望这篇文章能帮助你绘制出属于自己的 AOT 技术地图并在实际动手时清楚地知道——“我现在在哪里前方还有哪些山脉要翻越”。 
长河君 · 2026/8/10 16:49:44 · 阅读 1.2k 构建一个教学级 C# AOT 编译器：从 IL 到 C++ 的完整技术地图
构建一个教学级 C# AOT 编译器从 IL 到 C 的完整技术地图0. 前言为什么你需要了解 AOT 的全景.NET 的 AOTAhead-of-Time编译不仅仅是一个“把 IL 变成机器码”的翻译器。从开源的 CoreRT 到产品化的 NativeAOT一套工业可用的 AOT 工具链需要同时解决代码生成、依赖分析、垃圾回收交互、异常处理、反射静态化、泛型膨胀控制、互操作、线程模型以及运行时接线的数十个工程难题。这些难题每一个都足以成为独立的课题而把它们缝合为一个可工作的系统的“端到端E2E接线”能力更是从玩具到产品的分水岭。本文无意实现一个生产级编译器而是以教学为目的勾勒出一张覆盖全部关键点的技术地图。我们会沿着一条简化的 AOT 编译管线逐一探讨下列主题依赖分析与树摇裁剪、泛型共享与代码膨胀管理、去虚拟化与内联、反射与元数据处理、代码生成栈压低、InternalCall 的端到端接线、精确 GC 与帧根优化、异常管理与栈展开、调用堆栈生成、互操作与线程支持、启动与内存优化字符串池、内存池、碎片整理以及常被忽略的折叠、压缩与跟踪。全文的核心思想是在每一个技术点上我们都会给出“教学版可以怎么做”的极简实现思路并同时点明工业界为此付出的真实工程代价。对于每个模块我们还会标注其实现难度⭐⭐⭐⭐⭐⭐以便读者制定学习路线。读完本文后你将能理解 .NET NativeAOT 这类框架为什么会有那么多限制也会知道如果想自己从零写一个 AOT 编译器每一步该往哪个方向走。1. 系统总览编译管线与运行时库一个完整的 AOT 编译器由两部分构成编译时工具链ILC和运行时支持库。编译时工具链的输入是已由 C# 编译器Roslyn生成的托管程序集输出是包含原生机器码、EEType 表、泛型字典、元数据块和异常表的对象文件随后通过平台链接器生成单个可执行文件。它的工作流程大致为[.NET DLLs] → 依赖图构建与裁剪 → 泛型实例化决策 → 去虚拟化/内联 → IL到机器码翻译 → 生成数据节与元数据 → 链接 → [Native Exe]教学版编译器为降低复杂度通常会把“IL 到机器码”这一步替换为“IL 到 C 源码”的转译再利用普通 C 编译器完成最终编译。这样能绕过寄存器分配和指令选择的细枝末节把精力集中在 AOT 独有的系统问题上。即便如此我们仍然需要设计一个与之配合的极简运行时库负责对象分配、GC 接口、类型系统基座和异常投递。推荐工具链使用Mono.Cecil解析程序集自行编写依赖分析器和 C 代码生成器运行时库以少量 C 文件提供最后用clang或平台对应的 C 编译器将生成的源码与运行时库链接为可执行文件。2. 依赖分析与树摇裁剪 ⭐⭐⭐⭐⭐⭐2.1 问题描述托管程序集包含程序引用的所有方法、类型和字段但实际运行中可能只有一小部分被用到。JIT 模式按需编译天然具备“软裁剪”能力AOT 则必须在编译期以不可恢复的方式删除无用代码否则镜像尺寸会失控。2.2 核心机制根集合 可达性图AOT 编译器会从一个根集合出发通过静态调用图、类型继承关系和反射指令分析递归地标记所有可达的代码和数据节点。根集合通常包括程序集入口点、显式导出的方法、反射保留指令rd.xml 或注解、Interop 与 P/Invoke 桩。编译器以方法、类型、EEType、接口映射等为节点以“调用”、“继承”、“类型使用”、“反射可见”等为有向边构建一张依赖图。从根开始遍历未被标记的节点就被视作“死代码”并丢弃。教学版实现可用Mono.Cecil手工实现递归的 Mark-and-Sweep先标记所有根遍历 IL 指令遇到call、newobj、ldtoken等递归标记被引用成员。虚调用保守标记所有可能重写反射要求显式声明保留如keep.xml。2.3 库边界与框架依赖的裁剪困境 ⭐⭐⭐⭐教学版通常只处理单个程序集或极少的依赖因此依赖分析看似简单。但在工业环境下一个实际应用往往引用数十个甚至上百个系统库如System.Collections、System.Linq、System.Net.Http而不可能把整个 .NET 框架库全编译进镜像。ILC 必须精确判断一个库的哪些类型和方法因为应用的实际调用而被需要库与库之间的依赖如何传递例如System.Linq.Enumerable.Select内部使用了System.Collections.Generic.IEnumerableT只需裁剪出这两个具体相关的最小集合而不是拉入整个System.Linq和System.Collections。反射依赖往往隐藏很深一个类型名称字符串可能导致一整个继承链被拉入。工业级工具依赖反射扫描器自动识别这些模式并生成最小化的元数据但判定“多少才够”极其困难——漏掉一个运行时就会抛出MissingMetadataException多保留镜像就无谓膨胀。更复杂的是某些依赖只有在特定平台或配置下才生效条件编译、平台特定实现编译器必须了解这些上下文。教学版完全忽略这些边界手工裁剪几个程序集工业级则需要维护庞大的元数据标注如DynamicallyAccessedMembers特性和复杂的图算法才能接近理想镜像尺寸。3. 泛型共享与代码膨胀管理 ⭐⭐⭐3.1 问题的起源C# 泛型在 IL 层面是完整保留的例如Listint和Liststring是两个不同的实例化拥有自己独立的 EEType 和可能独立的 JIT 代码。AOT 编译如果为每一个可能的实例化都生成一份专用机器码会造成严重的代码膨胀特别是引用类型参数如Listobject、ListStream等在运行时行为完全一致它们的代码完全可以共享。3.2 共享策略canonical 代码 泛型字典工业 AOT 的做法是将引用类型参数的泛型实例化统一“规范化”canonicalization。例如所有Listobject、Liststring、ListMyClass共享同一份规范化代码而代码中访问泛型上下文的部分如对T类型的操作则通过一个隐藏的泛型字典参数来间接获取。字典中存放了实际类型的 EEType 指针、方法入口、接口实现等信息。值类型实例化Listint等因为内联需求和内存布局差异则仍然保留专用代码。在实现中泛型字典的布局由DictionaryLayout描述槽位索引在编译期确定。工业系统NativeAOT还支持惰性字典扩展——编译期只分配部分槽位运行时 TypeLoader 可以按需补充从而在镜像大小和动态性之间取得平衡。3.3 教学版泛型处理教学版编译器可以采取一个中间策略有限值类型实例化 引用类型全部共享。具体来说在依赖分析阶段收集所有实际出现的值类型实例化如Listint、Nullabledouble为它们生成专用代码对于所有引用类型实例化只编译一份 canonical 版本并在调用点传入一个运行时构造的字典。字典的实现可以很简单在 C 端每个泛型类对应一个DictionaryLayout的静态数组槽位索引在编译期确定运行期只需通过指针加偏移读取。例如ListT.Add(T item)的字典可能包含T的 EEType 指针用于类型检查或default(T)的初始化。教学版可以不处理惰性扩展整个字典在编译期静态分配即可。这样代码量从O(引用类型实例化数)降为O(1)显著减轻镜像膨胀。教学中可以清楚地看到一个小小的字典参数如何解决了代码共享问题。4. 去虚拟化与内联 ⭐⭐⭐⭐4.1 去虚拟化虚方法调用callvirt在运行时需要通过 vtable 或接口分派表间接跳转开销较大且阻止内联。AOT 编译时的去虚拟化Devirtualization旨在将那些可以静态证明其目标的虚调用转为直接调用。对于sealed 类、sealed 方法或者类型不可继承的情况编译器可以安全地去掉间接层。进一步如果编译器能进行全局可见性分析证明某个类在程序内不可能再有子类也可以将其视为有效密封effectively sealed。教学版编译器可以做一个简单的去虚拟化在依赖图遍历时如果发现某个虚调用的this类型是 sealed或者调用解析结果在闭包内只有一个可能的重写就直接把callvirt替换为call。更复杂的整程序分析如对public类的保守判定可以省略直接保留虚调用即可。4.2 内联内联通常由后端完成但在 AOT 中去虚拟化给内联创造了极大的机会——一旦虚调用变成直接调用内联器就可以看穿函数体把代码合并到调用者中进而消除调用开销产生更大的优化窗口。教学版如果采用 C 转译最简单的“内联”就是直接在生成 C 时把被调用函数体展开但这会破坏代码结构。一个更清晰的做法是依赖 C 编译器的优化能力如果我们把去虚拟化后的方法声明为inline并在同一个编译单元中生成C 编译器自然会完成内联。真正涉及跨函数边界的 IR 合并可以留作高阶练习。5. 反射与元数据静态化动态能力 ⭐⭐⭐反射是 .NET 的重要特性但它依赖完整的元数据类型名、成员签名、属性等。AOT 编译默认只保留代码元数据被大量剥离。为了让反射可用必须提前决定“哪些反射操作需要在运行时工作”并把相应元数据嵌入镜像。教学版编译器可以简单要求使用者提供一个配置文件类似rd.xml明确列出所有需要反射支持的类型和成员。编译器将这些类型和成员的类型信息结构体、名称字符串、签名 blob生成到 C 全局数据区并注册到一张反射表中。运行时的Type.GetType()和MethodInfo.Invoke()则通过这张表查找。对于“按名称查找”的需求字符串和签名的存储本身会占据较大空间这涉及到元数据压缩与折叠。工业上会使用二进制格式如 NativeLayout并去除调试信息教学版则可以直接用 C 的字符串常量并利用链接器的字符串合并能力来减少重复。反射的另一大负担是“动态实例化泛型”和“动态方法调用”。这超出了静态 AOT 的范围大多数教学实现会直接将其列为不支持。如需支持必须引入运行时的 TypeLoader 和按需 EEType 生成机制这是一个高难度模块⭐⭐⭐⭐。6. 代码生成从栈式 IL 到 C 的两种路径 ⭐⭐⭐⭐⭐即使已经完成了依赖裁剪和高级优化最终仍然需要把 IL 翻译成 C 或机器码。教学语境下有两种流行路径路径 A解释器固化模式每条 IL 指令直译为对std::vectorRuntimeValue的操作控制流用goto实现。这相当于把解释器固化在了源码中实现极其简单但不产生任何优化效果运行时性能低。路径 B栈压低Stack Lowering通过分析 IL 的栈行为将每个临时的栈槽映射到 C 局部变量。例如ldarg.0→int32_t tmp0 a;add→int32_t tmp1 tmp0 tmp1;。这需要遍历指令并维护一个符号化的栈深度为每一层栈槽分配临时变量名。之后可以删除冗余赋值进行简单常量折叠。路径 B 生成的代码更接近人类编写也更容易被 C 编译器优化。本文推荐采用路径 B 作为教学进阶版它的核心是一个单遍的栈模拟只不过将模拟结果“记录”为变量。同时我们可以顺手实现一些基本优化如常量折叠ldc.i4 3; ldc.i4 5; add直接生成8和无用指令裁剪对从未读取的局部变量不再生成赋值。7. E2E 接线编译代码如何与运行时库对话 ⭐⭐⭐⭐⭐⭐⭐⭐⭐这是经常被新手忽视、但工业上最核心的难点之一。编译出来的 C 函数并不能独立存在它需要调用运行时库提供的服务——分配对象、写屏障、类型检查、抛出异常等。这些服务在 JIT 中是 VM 直接提供的AOT 则需要通过稳定的符号接口进行连接。7.1 InternalCall 的直接映射托管代码中大量核心功能是以internalcall方式在 CLR 内部实现的例如对象分配、类型检查、字符串操作、线程同步、数学函数等。AOT 编译器必须为每个这样的调用点生成对运行时正确函数的调用。7.2 内部调用的数量与正确性挑战完整的 .NET CLR 内部调用函数数量极为庞大——接近两千个。这包含最基础的System.Object.GetType()、System.String.FastAllocateString()到复杂的System.Threading.Monitor.Enter()、System.GC.Collect()等。在教学版中我们可以只实现几个关键的如new、cast来跑通简单示例。但工业级 AOT 编译器必须逐一切实实现这些函数并且不能出错因为生成的代码会直接调用它们任何签名不匹配、语义偏差或线程安全问题都会导致程序崩溃或未定义行为。教学版可以完全回避这一难题——将internalcall替换为简单的 C 模拟例如Thread.Sleep直接调用std::this_thread::sleep_for。但工业级实现需要为每一个内部调用提供等价的 C 实现确保与 JIT 模式下 CLR 的行为一致。处理平台差异Windows/Linux/macOS 的线程原语、文件系统 API 等完全不同。维护这些实现与 .NET 版本同步——.NET 每版都会增加或修改内部调用AOT 运行时库必须跟随更新。正是这近两千个内部调用的精确实现构成了工业 AOT 运行时库的主体工作之一也是看似“重复造轮子”却无法避免的浩大工程。7.3 GC 写屏障托管堆中引用类型字段的写入必须通过写屏障通知 GC。例如obj-field other会被转译为__runtime_assign_ref(obj-field, other);。该写屏障内部会更新卡片标记并可能触发 GC。教学版可以使用简单的引用计数作为 GC 替代此时写屏障只需处理引用计数的增减。但如果要模拟精确 GC就必须在每次写引用时插入写屏障这是 E2E 接线中的典型例子。7.4 互操作与线程支持P/Invoke 调用、委托封送以及线程模型是 AOT 的另一大接线战场。教学版可将 P/Invoke 简单映射为extern声明ThreadStatic字段用 C11 的thread_local模拟lock语句用std::mutex替代。工业级则需处理封送 thunk、委托回调、ABI 转换等每一项都极为繁重。8. 精确 GC 与帧根优化 ⭐⭐⭐⭐要支持 GC就必须让 GC 能够找到所有正在使用中的托管引用——这些引用可能位于寄存器、栈帧或静态变量中。JIT 编译时会生成“GC 信息”来描述每个安全点处哪些位置有根。AOT 编译器同样需要生成这些信息否则 GC 会误回收仍在使用的对象或留下悬空引用。8.1 教学版的“显式帧根”方案最简化的精确 GC 方案是在编译时为每个函数生成一个__gc_roots数组包含所有栈上对象的指针的指针。在每次可能触发 GC 的调用如分配对象前更新这些指针GC 扫描时直接遍历这个根数组。这种主动注册根地址的方式称为显式帧根它不同于“保守式栈扫描”后者是把整个栈当作指针来推测是精确 GC 的一种简化教学实现。例如一个函数voidMyFunc(){Object*a__runtime_new_object(...);Object*b__runtime_new_object(...);}可以被转译为voidMyFunc(){Object*anullptr,*bnullptr;FrameRoots __roots{a,b};__runtime_push_frame(__roots);a__runtime_new_object(...);b__runtime_new_object(...);__runtime_pop_frame();}这样 GC 在发生时只要遍历当前线程的所有帧根链表就能找到所有活动引用。需要留意的是若编译器删除了“已无用”的变量赋值但该变量的地址仍在帧根数组中GC 会看到一个过期值可能造成对象被错误保留。工业系统通过精确的 GC 信息编码和活跃变量分析避免此问题。8.2 帧根优化所谓“帧根优化”就是减少需要报告的根的数量。例如如果某个局部变量在某个调用之后不再使用那么在该调用之后的安全点它可以被排除出根集合。这需要活跃变量分析教学版可以选择不做或手动在 IL 层识别。9. 调用堆栈与异常管理 ⭐⭐⭐9.1 调用堆栈为了在异常发生或调试时能输出托管堆栈追踪每个托管函数调用都需要在进入时注册一个“栈帧”到线程本地链表。帧中包含了调用者的返回地址和方法标识。简单实现可以在每个转译后的函数开头加入类似__runtime_push_frame(EETypePtr, __frame)的代码函数返回前弹出。这里的push_frame指的是向调用堆栈注册一个新帧与上一节 GC 的帧根报告根地址是两套机制应在命名或文档中明确区分。9.2 异常处理托管异常处理远比throw/catch复杂它要求支持catch的类型过滤和finally的保证执行。完整实现需要生成平台特定的展开表如 Windows SEH、Linux DWARF。这难度极大教学编译器可以通过编译期展开来回避将try-catch-finally结构在 IL 层面直接转换为带有跳转判断的goto代码。但要注意finally块的保证执行要求每个return、break、甚至异常出口都必须先执行finally块。实现时需要在每个可能的出口前复制或跳转到finally代码这增加了代码生成的复杂度。若catch块缺失则直接调用abort()。工业编译器如 CoreRT则将 IL 的异常处理子句翻译为展开表由运行时统一调度。这也是其移植性难度大的原因之一。10. 内存管理与优化字符串池、内存池、碎片整理、折叠与跟踪 ⭐⭐⭐⭐⭐⭐⭐除了代码生成运行时内存管理是工业 AOT 的另一大支柱。教学版通常直接调用 C 的new/delete或malloc完全依赖系统堆忽略托管内存的固有需求。而工业级 AOT 必须在以下方面做深度优化10.1 字符串池托管代码中大量使用字符串字面量。JIT 模式将字面量“内化”intern到运行时字符串表重复字符串共享同一份内存。AOT 编译时必须预生成这个字符串池编译期收集所有ldstr引用的字面量在镜像数据段中分配只读字符串对象全局唯一。运行时String.Intern直接从该池查找。这不仅能节省内存还能加速字符串相等比较引用相等。工业实现还需处理动态生成的字符串如StringBuilder结果是否需要入池的复杂策略。10.2 内存池与对象分配频繁的小对象分配如new object()、临时数组直接调用系统堆会使性能大幅下降。工业 GC 使用代际generational管理并预分配内存池heap segments。AOT 编译产物与 GC 深度集成分配辅助函数RhpNewObject不仅从 GC 堆的分配上下文中快速指针搬运bump-pointer还需在 GC 发生时配合压缩/移动。此外静态分析可为某些类型预先保留内存池或使用“冻结段”将已知生命期对象置入只读内存。10.3 内存碎片整理与对象移动托管堆在长期运行中会产生内存碎片。工业 GC 通过压缩compaction阶段移动存活对象合并空闲块。这就要求 AOT 编译器生成精确的GC 信息不仅报告哪些位置有根引用还要报告引用的基地址和位置以便 GC 移动对象后更新所有指向它的指针。生成的 C 代码若直接使用原始指针Object*在移动式 GC 下将全部失效——工业方案中AOT 代码或使用手柄handles或配合 GC 在安全点暂停并批量修正指针。教学版完全避开此问题通常使用不可移动的引用计数或保守 GC。10.4 折叠、压缩与 PGO常量折叠与删除编译期计算常量表达式。元数据压缩类型名、签名字符串合并到全局表去重。PGO跟踪利用运行时反馈优化去虚拟化和内联决策。11. 一张全景表教学版做了什么没做什么技术点难度教学版实现工业级补充依赖分析/裁剪⭐⭐⭐⭐⭐⭐手工标记递归遍历反射需手工配置保留自动反射扫描、库边界依赖传递、按需类型生成、接口分析泛型共享⭐⭐⭐引用类型 canonical 简单字典值类型预实例化惰性字典扩展、UniversalCanon去虚拟化⭐⭐仅对 sealed 类生效全程序可见性分析、有效密封推断内联⭐⭐依赖 C 编译器或简单展开跨程序集内联、PGO 决策代码生成⭐⭐⭐⭐⭐IL 栈压低为局部变量简单常量折叠寄存器分配、向量化、深度内联反射与元数据⭐⭐⭐手动配置保留编译期生成查找表无动态生成反射扫描器、NativeLayout、按名重建内部调用实现⭐⭐⭐⭐⭐实现 5~10 个关键 helper其余用 C 近似替代近 2000 个 internalcall 逐个正确实现平台适配E2E 接线⭐⭐⭐⭐硬编码 helper 函数列表手写调用映射全自动符号解析、ABI 适配、GOT/PLT 处理精确 GC⭐⭐⭐⭐显式帧根链表扫描不可移动对象精确 GC 信息编码、寄存器扫描、移动式 GC异常处理⭐⭐⭐编译期展开为goto需小心 finally 保证平台展开表完整 finally 保证调用堆栈⭐⭐手工压入/弹出托管帧与 GC 帧根区分基于展开信息的回溯互操作与线程⭐⭐⭐⭐⭐⭐⭐简单 P/Invoke 映射、thread_local模拟封送 thunk、委托回调、ABI 转换、线程模型集成启动优化⭐⭐手动预初始化构造结果硬编码冻结段、泛型预初始化、启动序列优化字符串池⭐⭐⭐无使用 C 原生字符串字面量或每次动态分配编译期全局字符串池、字面量去重、String.Intern支持内存池⭐⭐⭐⭐直接调用new/malloc无托管分配优化GC 代际堆、bump-pointer 分配、对象池、冻结段碎片整理/移动⭐⭐⭐⭐⭐无移动对象固定不动引用计数或保守 GC压缩式 GC、对象移动、全局指针修正、写屏障增强代码膨胀控制⭐⭐⭐泛型共享 树摇PGO 去虚拟化、轮廓导向内联调试信息⭐⭐可选生成#line指令映射回 C# 源码完整 PDB/DWARF 生成、序列点与内联帧还原12. 端到端最小示例为提供可复现的起点这里给出一个极简的“静态方法加法”转译全流程。C# 输入Add.cs编译为 Add.dllpublicclassCalculator{publicstaticintAdd(inta,intb)ab;}IL 核心片段IL_0000: ldarg.0 IL_0001: ldarg.1 IL_0002: add IL_0003: ret转译器生成的 C 代码基于栈压低路径// 运行时基础定义略#includeruntime.hint32_tCalculator_Add(int32_ta,int32_tb){int32_t__tmp0a;int32_t__tmp1b;int32_t__tmp2__tmp0__tmp1;return__tmp2;}构建命令示意# 1. 用 Roslyn 编译 C# 为 DLLcsc /t:library Add.cs# 2. 运行自制转译器C# 编写读取 DLL生成 C 源码dotnet run--projectMyAotCompiler -- Add.dll output.cpp# 3. 用 C 编译器将生成的源码与运行时库链接clang-oadd_app output.cpp runtime.cpp ./add_app# 自行添加调用代码测试这个示例刻意省略了对象分配、GC、异常等复杂特性仅展示最基础的算术运算转译。扩展它只需逐步增加指令支持、类型系统和运行时 helper 即可。13. 结语从“可用”到“工业级”的距离本文遍历了一个 AOT 编译器所必须面对的方方面面并给出了教学可用的简化方案。如果把这些简化实现逐一拼装我们能够在几周内构建出一个可以编译并运行简单 C# 程序的转译器——它拥有基本的依赖裁剪、泛型共享、简单的去虚拟化、显式的 GC 根和可工作的反射路径。这对于学习编译原理、运行时设计已经足够。然而工业级 AOT 与这个教学版之间的距离就是“可靠性”和“性能”的距离反射分析必须零遗漏、GC 信息必须比特精确、异常处理必须在每个平台上都符合 ABI、泛型字典必须保证线程安全的惰性初始化、启动性能必须优化到毫秒级、互操作封送必须处理所有边界情况……更重要的是内存管理必须提供高效的字符串池、预分配的内存池以及能整理碎片的移动式 GC依赖裁剪必须精确到库与库之间的边界近两千个内部调用必须逐个正确实现。这些都需要编译器、运行时和基础库三方在安全点精确协作对生成代码的每一条指针操作都施加精细的控制。这些问题的解往往不存在巧妙的捷径只有扎实的工程积累、数十万行的基础代码和大量的边界测试。一个值得深思的对比是 IL 解释器。像 ILRuntime 这样的解释器其工作原理是寄生在现有 .NET 运行时之上它通过反射或 Emit 动态调用底层 CLR 的服务对象分配、类型检查、字符串操作等解释器本身只需要处理 IL 的语义调度。若要提升性能只需在调度循环中加入更多静态特化的快速路径比如为常见指令编写case分支而完全不需要触碰运行时的底层实现——不需要自己写 GC不需要实现 InternalCall不需要处理平台 ABI也不需要做依赖裁剪。这正是解释器方案之所以“简单”的根本原因它没有跨出宿主运行时的边界所有复杂的系统服务都由现成的 CLR 提供。而 AOT 编译器的本质恰恰是脱离了这套现成的运行时。一旦你要生成独立可执行的本地代码你就必须自己提供所有运行时服务并且必须保证它们与原来 CLR 的行为语义等价。这份“等价性”的担保就是那近两千个内部调用、精确的 GC 协作、完整的异常展开和元数据重建。ILRuntime 可以借用、可以近似、可以在宿主运行时上搭建桥梁AOT 编译器却必须自建整座桥并让它承受全部流量。认识到这一根本性差异才能理解为什么“简单的 IL 转译器”和“真正的 AOT 编译器”之间隔着的是整个运行时工程的鸿沟。希望这篇文章能帮助你绘制出属于自己的 AOT 技术地图并在实际动手时清楚地知道——“我现在在哪里前方还有哪些山脉要翻越”。