aot编译是将c#代码在部署前直接编译为原生机器码的技术，.net 8中已完善支持，相比jit可显著提升启动速度、减小依赖，适用于serverless、微服务和cli工具；其优势包括冷启动时间降低50%以上、部署包更精简，但存在不支持动态代码生成、需适配aot友好库等限制。
.NET 中的 AOT 编译是一种在应用部署前将 C# 代码直接编译为原生机器码的技术，不同于传统的即时编译（JIT），它在运行时不再需要动态编译，从而显著提升启动速度并减小运行时依赖。这一特性特别适用于对冷启动时间敏感的场景，比如 Serverless 函数、微服务和 CLI 工具。
什么是 AOT 编译？
AOT（Ahead-of-Time）编译在构建阶段就把托管代码转换为特定平台的原生二进制文件。这意味着应用启动时无需 JIT 编译器参与，减少了 CPU 和内存开销。.NET 7 开始引入实验性 AOT 支持，.NET 8 进一步完善，支持更多应用场景。
与传统的 IL（中间语言）不同，AOT 输出的是静态链接的可执行文件，包含所有必需的代码和运行时组件，因此不需要目标机器上安装 .NET 运行时。
提升启动性能
AOT 最直观的优势是极快的启动速度。由于所有代码已经编译完成，应用可以直接执行，避免了 JIT 编译的延迟。这在以下场景中尤为关键：
- Serverless 平台如 Azure Functions 或 AWS Lambda，按执行时间计费，快速启动意味着更低成本
- 微服务架构中频繁启停服务实例
- 桌面工具或命令行程序，用户期望“秒开”体验
实测表明，启用 AOT 的 .NET 应用冷启动时间可减少 50% 以上，部分简单场景甚至接近原生 C++ 程序的响应速度。
减小部署体积
虽然 AOT 生成的单文件可执行程序初始体积可能比 DLL 大，但它通过剪裁（trimming）技术移除未使用的代码，最终部署包通常更精简。特别是配合 PublishTrimmed 和 IlcGenerateStackTraceData=false 等设置，可进一步压缩输出。
更重要的是，AOT 发布不需要附带完整的 .NET 运行时，大幅降低部署包大小。例如，一个简单的 Web API 使用传统发布方式可能需要 100MB+，而 AOT 单文件发布可控制在 30~50MB 范围内，更适合容器化部署。
使用限制与注意事项
AOT 并非万能，目前仍有一些限制需注意：
- 不支持反射 emit 和动态代码生成（如 System.Reflection.Emit）
- 部分依赖运行时代码生成的库（如某些 ORM、JSON 序列化器）需适配 AOT 友好版本
- 调试信息较少，堆栈跟踪可能不完整
- 仅支持发布配置，且必须指定目标运行时（如 win-x64、linux-arm64）
推荐在项目文件中启用 AOT：
<PropertyGroup> <PublishAot>true</PublishAot> <SelfContained>true</SelfContained> <RuntimeIdentifier>linux-x64</RuntimeIdentifier> </PropertyGroup>
基本上就这些。AOT 让 .NET 应用更轻更快，虽然生态适配仍在进行中，但对于新项目或对启动性能有要求的服务，值得尝试。不复杂但容易忽略的是：确保所用库已标记为“AOT 兼容”，可通过 NuGet 包的文档或 GitHub 仓库确认。
