ASP.NET MVC项目预编译的优势是什么？启动慢问题咨询

我太懂你遇到的这种糟心情况了——首次访问慢得离谱，好不容易后续访问顺畅了，第二天一睁眼又回到解放前，本质这就是应用冷启动在搞鬼：ASP.NET MVC默认会在首次处理请求时，临时去编译视图、加载零散的代码文件，这个过程真的很耗时间。预编译正是瞄准这类场景设计的，下面我把它的核心优势给你掰扯清楚：

• 彻底砍掉视图动态编译的开销
  默认情况下，ASP.NET MVC要等用户第一次访问某个.cshtml/.vbhtml视图时，才会做语法检查、生成中间代码、编译成IL程序集这一整套操作，这就是你首次访问卡壳的主要原因之一。而预编译会在发布阶段就把所有视图提前编译好，部署到服务器后根本不需要再做动态编译，第一次请求就能直接跑编译好的代码，从根儿上解决视图层面的冷启动延迟。

• 大幅缩短应用启动的整体耗时
  预编译不光处理视图，还能把项目里的控制器、模型这些代码文件一起预编译成单个或几个打包好的程序集。相比服务器启动时零散加载源文件，预编译后的程序集加载速度快得多，尤其是大型项目，启动时间能砍半甚至更多。

• 把编译错误扼杀在发布阶段
  动态编译的坑在于，视图里的语法错误只有用户访问到那个页面时才会炸出来，直接影响用户体验。预编译会在发布时就把所有视图和代码的编译问题都揪出来，提前修复，不至于上线后突然掉链子。

• 降低服务器资源的波动消耗
  运行时动态编译会占服务器的CPU和内存，要是赶上高并发场景，好几个首次请求同时触发编译，服务器直接就卡成PPT了。预编译把编译工作转移到了发布阶段，服务器只需要执行现成的编译代码，资源利用率会稳定很多，不会突然出现资源占用飙升的情况。

• 支持灵活的部分预编译（按需优化）
  如果你不想全量预编译，ASP.NET MVC也支持部分预编译——比如只预编译首页、商品列表这些高频访问的视图，把一些冷门页面留作动态编译，平衡发布时的编译时间和启动速度。不过针对你遇到的次日重启变慢的问题，全量预编译应该是最对症的方案。

最后得说清楚：预编译确实没法保证“任何时刻请求都快如闪电”——比如服务器回收应用池后，应用重新启动还是需要加载预编译的程序集，但这个加载速度已经比动态编译快太多了，用户基本感知不到延迟。你说的次日再次变慢，大概率是应用池自动回收导致的冷启动，预编译能把这个冷启动的耗时压缩到最低。

内容的提问来源于stack exchange，提问作者Biao