AOT项目在发布时，可以通过项目文件中的OptimizationPreference选项来生成理论上最快的可执行文件（Speed）和更小的可执行文件（Size)， 默认情况下，编译器选择混合方法：生成快速代码，大小又适中。通过在<PropertyGroup>中增加如下节点即可：

<PropertyGroup>
    ……
   <OptimizationPreference>Size</OptimizationPreference>
</PropertyGroup>

下面是优化完后的结果，并且做了性能测试，从结果来看，Seep的不一定比默认的快，当然，快和慢与测试的接口和使用的库有很大关系，不能一概而论，所以那种方式发布，一定要通过自己的性能测试来决定，不盲信，不育从。

AOT项目在发布时要选择对应平台，因为AOT项目只支持编译出当前平台上的Native代码，并且在发布时，要选择独立发布，这将会把AOT项目本身的代码和经过裁剪的库打成一个执行文件，否则会报错。

另一方面，AOT项目发布真叫慢，因为他不但分析项目与AOT要求有没有错误，警告，还要用源生成器把特定代码转换成AOT的适配合代码，然后裁剪，提取依赖包，然后用对应平台的编译器编译成Native代码，所以整个过程要比普通的.NET慢的多，基本是以分钟为单位。希望未来这块能加速。

AOT项目其实更适合云原生，体积小，占内存少，启动快，首次请求也快等特点，几乎就是为了容器中的服务而生。所以在发布镜像时，我们可以针对性地选择镜像的基层。目前，通过Visual Studio创建的docker化的AOT项目，运行时基础镜像用的是mcr.microsoft.com/dotnet/runtime-deps:8.0 ，这个镜像发布出来有240多M，如果有镜像尺寸优化，可以用ubuntu，就会到200M，如果要求更小，就只能基于alpine自己进行裁剪来测试服务的可用性了。

AOT项目上生产，我个人感觉处于开始阶段，技术本身的成熟度，配套工具的完善化，三方库的适配度，都需要一些时间，所以谨慎使用，即使用，也要尽可能进行性能测试，确保业务万无一失。同时也期待AOT技术更快更好地发展。