.NET 11 RC1 发布在即。借这个时间点，聊聊 .NET 憋了四年的一招——Native AOT，以及它为什么直到今天才接近"能用得好"。
在 .NET 8 之前，.NET 对标的从来都是 Java：JVM 对 CLR，Maven 对 NuGet，Spring 对 ASP.NET Core——大家都是"虚拟机 + 大厂企业级"的路数，比的是生态厚度、LTS 策略和工具链。
但 Go 走了另一条路：编译期直接出原生机器码，单文件部署、毫秒级启动、几十兆内存跑一个服务。在容器和 Serverless 时代，这套打法刀刀砍在 JVM/CLR 系语言的软肋上——你还在等 JIT 预热，人家的容器已经弹起来又缩回去了。
.NET 要还手，答案只有一个：Native 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 下载榜前排的老将们是怎么工作的：
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 化的最大摩擦力。
给个诚实的分期判断：
dotnet new 一样自然。道理讲得再多，不如看一个真把 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 思维"已经渗进了产品决策：
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。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。