为什么.NET 团队在支持AOT上这么拉胯？ 第1页

事实上与这些人不同的是我反对加强AOT支持！

加强AOT支持不仅仅会分散团队的注意力，更重要的是，AOT兼容性很可能阻碍C#语言的进一步发展。如果过于关注AOT支持，有可能让C#开发团队在引入新的特性时过于顾及AOT的影响。

更何况，随着C#语言的演进，支持AOT的部分必然会分化出一个语言子集出来，这进一步增加了复杂度……

nativeaot这种东西要想好好用，得有另一个生态，这个生态里的类库都是为aot准备的，他们已经为aot做好了配置，aot友好，然后没有ilemit等特性，也就是说以往很多实用类库都不再能使用，得出另一个版本。这意味着也就做做小工具方便，对企业级应用来说永远不会比有jit方便，不如无依赖编译。

nativeaot好处是可以让程序脱离il代码，急剧增加破解难度，比无依赖编译显著减小体积，加快启动速度，做做小工具还是可以的

虽然很多部署人员喜欢体积小无依赖，都已经有docker了居然还这么懒。。。诶

所以你看go很多特性是没有的，不知道go将来可以在aot下做到什么程度，但特性肯定要比.net的jit差的远，而.net一开始也没有为aot考虑过什么，特性太多导致支持困难。

目前看起来表达式树也基本支持了，不过可能还不够完整，得各个包的作者积极配合进行自查，大多数作者还没搞清楚rd.xml怎么配置呢吧，我也没搞清楚，如果目前支持的功能都没什么问题了，那么大多数包还是可以支持到项目的，使用的范围会比想象的大一些，态度也会从小工具自己用着玩，变成稍微正经点的软件也能用了，只不过自己以为用了个轻量级的dapper的人，反而搞不了aot，用了efcore这种给人感觉比较重的，反而可以aot，freesql是使用表达式树的，插入数据可以，查询数据我跑不通，只能等以后研究了。

如果wpf不能用有些可惜

要说需求的话，aot多少也是有硬需求的，这也是很多地方选go的原因，现在的很多人就以go这种形态为方便的标准。还有就是我上面列的优点适合小工具。

要说没需求吧，像我个人更喜欢依赖运行时，这样子给出的dll能直接跨平台部署让运维去搞不好么，或者说做成docker了和aot也没啥关系了，确实没必要和go拼场景