什么项目适合AOT呢？那要先看AOT项目的优缺点有哪些，根据这些优缺点，我们就能判断自己的项目适合不适合用AOT模式开发。

下面是官方提供的一个.NET服务原生发布与AOT的比较，我们看到，在Linux下，大小几乎是原来的1/10，启动后工作内存，不到原来的一半，启动时间更是原来的1/4，而带来的RPS损失只有1/10；还是在Windows下，发布的大小更进一步，只有8.87M，不过内存是原来的一半以上，首次启动时间也要长一些，也是原来的1/4左右，损失的RPS只有5%左右，可以AOT项目带来的改善还是很明显示的，特别是当把应用发布到容器里时，占用资源明显降低，这对于容器的缩放很有利处。

从上可知，AOT的项目更小，即打包发布的程序包，或发布的Image都更小一些；第二就是更少，运行时占用内存更少，这为多副本应用节省了宝贵的内存资源（相当于省钱呀）；第三就是首次启动更快，也就是冷启动更快，这为开发一些Funcation服务提供了可能。

说完了优点，现在说说缺点吧。首先AOT项目对反射，序列化，与原来的开发有较大的差别，所以不是一键切换。再就是，在调试模式，软件的表现，与AOT发布后的表现有可能不一样，毕竟调试模式，并不是在运行机器码。这两点是使用AOT开发最大的障碍，几乎所有功能都要以AOT发布后的结果为准，这就使开发效率没有原来那么高。再有一点就是现在的一次发布，可以用龟速来形容，所需的时间用来冲一杯咖啡都还有剩余。

缩合上面的分析，我们可以得出下面三类应用适合用AOT方式开发发布：
1.FaaS类服务，对于一些复杂算法，独立计算类小服务，可以用AOT来发布。
2.对于一些基础服务，调用频率高，要求更高的性价比：占用资源少，产出高，比如上图的Linux下，如果采用AOT发布，我们启动两个Pod，资源用不到原来的一半，RPS却有大幅增加，这是很划算的性价。

3.再有就是一些简单，功能单一的业务服务也可以考虑用AOT发布，因为业务复杂的服务，所需的技术就会复杂，这对现阶段的AOT开发有一定的开发代价。等一等，有可能VS对AOT项目开发，调试，发布有很大改进，毕竟第一个吃螃蟹的人，有可能被夹嘴。