从对标 Java 到对标 Go：Native AOT 的"无痛化"之路，走到哪一站了？ - 张善友
内容提要
.NET 11 RC1发布在即，文章回顾了Native AOT从.NET 7到.NET 11的发展历程，强调其从demo级到企业可落地的进步。AOT面临反射兼容问题，需通过Source Generator解决。开源项目OpenClaw.NET展示了AOT在AI Agent场景的应用，通过能力分层平衡动态与静态需求。尽管生态转型缓慢，但NuGet下载量增长显示趋势向好，五年努力值得。
延伸解读
AOT 的瓶颈不在编译器，而在反射遗产
文章指出，Native AOT 真正让人头疼的不是开启 PublishAot 本身，而是大量 IL2xxx/IL3xxx 警告，根源在于反射。许多流行库的设计基于运行时反射，如 Assembly.GetTypes()、Type.GetProperties()，在 AOT 下无法预知类型，导致裁剪困难。解决办法是使用 Source Generator 将反射工作移到编译期。这提醒开发者，在采用 AOT 时，需优先关注依赖库的 AOT 兼容性，或寻找支持 Source Generator 的替代方案。
生态转型的摩擦力：Newtonsoft.Json 的启示
文章以 Newtonsoft.Json 单版本 8805 万次下载量为例，说明存量生态对 AOT 转型的阻力。下载榜前列的库多诞生于反射自由时代，其用户基数庞大，转身缓慢。尽管 BCL 已基本完成 AOT 适配，但第三方库的兼容性仍是企业落地 AOT 的主要障碍。这提示开发者，在评估 AOT 迁移时，需检查关键依赖是否已支持 AOT，或考虑使用 AOT 友好的替代库（如 System.Text.Json）。
OpenClaw.NET 的架构思路：用分层化解动态与静态矛盾
OpenClaw.NET 作为 NativeAOT 友好的 AI Agent 运行时，通过显式的能力分层（capability lanes）来平衡动态与静态需求：需要动态加载的部分保留在 JIT-only 泳道，而网关、CLI 等追求毫秒启动和单文件部署的部分则完全静态化。这种设计不硬抗 AOT 限制，而是将其转化为架构边界，值得借鉴。对于需要兼顾动态扩展和性能的场景，类似的分层策略可有效降低 AOT 的采用难度。
Q&A
Native AOT 在 .NET 中的发展历程是怎样的？
Native AOT 从 .NET 7 开始引入，最初仅支持控制台应用，属于 demo 级；.NET 8 开始支持 ASP.NET Core，镜像缩小到约 100MB，启动时间降至毫秒级；.NET 9 增强了修剪分析和 BCL 兼容性；.NET 10（LTS）补齐了工具链，进入企业可落地状态；.NET 11 进一步优化，二进制体积平均再降 25%，容器冷启动再降 40%。
为什么 .NET 需要 Native AOT？
因为 .NET 传统上对标 Java，采用虚拟机模式，但在容器和 Serverless 时代，Go 等语言通过编译期生成原生机器码，实现了单文件部署、毫秒级启动和低内存占用，对 .NET 构成挑战。为了与 Go 竞争，.NET 必须提供 Native AOT 能力。
Native AOT 面临的主要挑战是什么？如何解决？
主要挑战是反射兼容问题，因为 AOT 编译时无法动态解析类型，导致 IL2xxx/IL3xxx 警告。解决方案是使用 Source Generator，将运行时反射的工作转移到编译期代码生成。
OpenClaw.NET 是如何处理 AOT 与动态性之间的矛盾的？
OpenClaw.NET 采用显式的能力分层（capability lanes），将需要动态加载的部分（如插件）留在 JIT-only 泳道，而需要毫秒启动和单文件部署的部分（如网关、CLI）彻底静态化，从而平衡动态与静态需求。
Native AOT 在 .NET 11 中取得了哪些具体改进？
根据官方数据，.NET 11 的 Native AOT 支持库图规模继续扩大，二进制体积平均再降 25%，容器冷启动再降 40%（相对 .NET 10）。
为什么说 .NET 生态的 AOT 转型缓慢？
因为下载榜前列的库（如 Newtonsoft.Json）都是基于反射设计的，用户基数大，转向 AOT 需要时间。例如 Newtonsoft.Json 单版本下载量达 8805 万次，这成为生态 AOT 化的最大摩擦力。
Native AOT 对 AI Agent 场景有什么价值？
AI Agent 场景需要网关常驻、冷启动快、内存占用低，并能在树莓派等设备上运行，Native AOT 正好满足这些需求。OpenClaw.NET 就是利用 AOT 实现这些优势的实例。
