从对标 Java 到对标 Go：Native AOT 的"无痛化"之路，走到哪一站了？

.NET 11 RC1 发布在即。借这个时间点，聊聊 .NET 憋了四年的一招——Native AOT，以及它为什么直到今天才接近"能用得好"。

---

一句话回顾：.NET 的对手换了

在 .NET 8 之前，.NET 对标的从来都是 Java：JVM 对 CLR，Maven 对 NuGet，Spring 对 ASP.NET Core——大家都是"虚拟机 + 大厂企业级"的路数，比的是生态厚度、LTS 策略和工具链。

但 Go 走了另一条路：编译期直接出原生机器码，单文件部署、毫秒级启动、几十兆内存跑一个服务。在容器和 Serverless 时代，这套打法刀刀砍在 JVM/CLR 系语言的软肋上——你还在等 JIT 预热，人家的容器已经弹起来又缩回去了。

.NET 要还手，答案只有一个：Native AOT。

---

四年五步：AOT 成熟度时间线

2022 年，.NET 7：出生。 Native AOT 首次发布，但只支持控制台应用，限制一大堆——这是 demo 级，证明"能做"，不证明"能用"。

2023 年，.NET 8：成年礼。 ASP.NET Core 接入 AOT，Docker 镜像从 GB 级压到 ~100MB，启动从秒级降到毫秒级。这是 .NET 第一次真正拿到和 Go 同场竞技的门票。所以说".NET 8 才对标得了 Go"，没毛病。

2024 年，.NET 9：修炼。 修剪分析（trimming analysis）增强，BCL 兼容面扩大，但因为是 STS 版本，企业普遍观望。

2025 年，.NET 10（LTS）：工具链补齐。 警告体系、兼容性开关、裁剪分析全部到位，AOT 第一次进入"企业可落地"状态。这也解释了上一篇半年总结里的数据：.NET 10 SDK 工作负载包直接杀进 NuGet 版本级下载 TOP10，周下载量从 54 亿冲到 67 亿——迁移浪潮里很大一部分就是奔着 AOT 和云原生来的。

2026 年 9 月，.NET 11 RC1：临门一脚。 官方数据显示，.NET 11 的 Native AOT 支持库图规模继续扩大，二进制体积平均再降 25%，容器冷启动再降 40%（相对 .NET 10）。

---

真正的痛点不在编译器，在生态

骂过 AOT 的人都清楚：让你崩溃的从来不是 PublishAot=true 本身，而是那一屏屏的 IL2xxx/IL3xxx 警告——它们几乎全部指向同一个元凶：反射。

看看 NuGet 下载榜前排的老将们是怎么工作的：

• Newtonsoft.Json：运行时反射遍历类型元数据，想序列化谁就序列化谁——灵活，但对 AOT 裁剪是灾难；
• AutoMapper：运行时构建映射配置；
• EF Core：运行时构建实体模型；
• 各种 DI 容器：Assembly.GetTypes() 扫描注册。

这些库的设计哲学诞生于"反射自由"时代。每一个 Type.GetProperties()，都是 AOT 链接器眼里的一颗雷——它不知道你运行时会摸到什么类型，只能保守保留，要么裁剪过度直接运行时爆炸。

解法只有一个：Source Generator。 把运行时反射干的活，挪到编译期用代码生成干完：

反射时代	Source Generator 时代
Newtonsoft.Json	System.Text.Json source-gen 模式（性能已反超）
手写正则	RegexGenerator
日志字符串拼接	LoggerMessageAttribute
EF Core 运行时模型	Compiled Model
运行时配置绑定	Configuration.Binder 源生成器
REST 调用封装	Refit / 各 SDK 的生成式客户端

BCL 能做的已经做得差不多了。现在的瓶颈是存量生态——下载榜 TOP5 全是反射时代的老兵，它们的用户基数决定了转身速度。Newtonsoft.Json 单版本 8805 万次的下载量既是荣耀，也是整个生态 AOT 化的最大摩擦力。

---

所以，"无痛化"到底什么时候算完成？

给个诚实的分期判断：

• .NET 10（已达成）：工具链完成。警告可读、开关齐全、官方框架（ASP.NET Core、gRPC、Minimal API）全部 AOT 兼容。先锋团队可以上了。
• .NET 11（进行中）：指标再优化，库图继续扩。RC1 这一两周就发，11 月 GA。但注意它是 STS，支持到 2028 年 11 月，和 .NET 10 同日退役——它是试验场，不是主战场。
• .NET 12 LTS（2027 年 11 月，真正的终点线）：给库作者两年窗口期把 source generator 版本补齐，到那个时候，主流依赖全面生成化，AOT 体验才算"无痛"——新项目默认开 AOT，就像今天默认用 dotnet new 一样自然。

---

实战样本：OpenClaw.NET，一个"NativeAOT-friendly"的 AI Agent 运行时

道理讲得再多，不如看一个真把 AOT 当一等公民的项目。开源项目 OpenClaw.NET（GitHub: clawdotnet/openclaw.net，MIT 协议）是一个用 .NET 实现的自托管 AI Agent 运行时与网关，README 的第一句话就把自己定位成 "NativeAOT-friendly AI agent runtime and gateway for .NET"。

它最有参考价值的地方，在于正面回答了上一节的那个矛盾：Agent 系统天生想要动态性（插件、热加载、工具发现），AOT 天生想要静态性（编译期确定一切）——怎么调和？

OpenClaw.NET 的答案是显式的能力分层（capability lanes），写在架构文档里：

能力泳道	内容	与 AOT 的关系
Core	运行时循环、网关、CLI、OpenAI 兼容 API	完全 NativeAOT 化
Optional	浏览器/MQTT 协议包、渠道适配器、模型提供商、工作流后端	AOT 兼容的可选包
Experimental	嵌入式本地模型 sidecar（Gemma 4 GGUF 推理）	隔离为独立进程，不拖垮主程序 AOT
JIT-only	动态插件渠道、命令、钩子、原生动态 .NET 插件	诚实标注：这些就是不能用 AOT

这个设计值得抄作业的点是：它不和 AOT 的限制对抗，而是把限制画成架构边界。需要动态加载的部分老老实实留在 JIT-only 泳道；需要毫秒启动、单文件部署的部分（网关、CLI）彻底静态化。最终交付物是三个平台的桌面包——每个包里直接装着 NativeAOT 编译的网关和 CLI，用户解压即用，连 .NET 运行时都不用装。这正是 Go 用户习以为常、而 .NET 开发者过去只能眼馋的体验。

其他几个细节也能看出"AOT 思维"已经渗进了产品决策：

• 本地模型推理走 sidecar 进程（Gemma 4 GGUF 包 + 监督式推理进程），原生依赖与主程序的 AOT 编译解耦；
• 复用 SKILL.md 包与 TS/JS 插件生态，但走清单发现（manifest discovery）而非反射扫描——编译期可确定；
• 官方明确把 NativeAOT trimming 改进列为最欢迎的贡献方向之一。

AI Agent 恰好是 AOT 价值最大的场景：网关要常驻、冷启动要快、内存占用要低、还要能在树莓派级别的设备上跑——OpenClaw.NET 这种"把 AOT 写进产品定位"的项目，在一年前几乎不可想象，而今年开始冒出来，本身就是生态转向的信号。

---

结语

从 .NET 7 的 demo 到 .NET 12 的无痛化，这条路要走五年。慢吗？慢。但对比一下：Java 的 GraalVM Native Image 折腾了更久，至今 Spring 生态的 AOT 体验仍在打补丁；Go 则是天生就站在终点线上——.NET 是在背着二十年的反射遗产追赶一个轻装上阵的对手。

好在数据站在 .NET 这边：NuGet 周下载量半年 +24% 冲到 67 亿，.NET 10 迁移浪潮如期而至，OpenTelemetry、gRPC 这些天生 AOT 友好的库正在占领下载榜。生态的重力方向已经变了。

五年换一条起跑线，值了。

---

延伸阅读：《NuGet 半年度总结：周下载量从 54 亿到 67 亿》；OpenClaw.NET 仓库：（文档站 AgentQi.dev）；.NET 11 RC1 发布动态见微软 .NET 官方博客；实时数据见 nuget.org/stats。