Vite 8.1 把打包引回了开发环境——万级模块的冷启动，这次不用等了

Vite 用了七年「不打包」的思路做开发服务器，现在它自己把这个结论推翻了——Vite 8.1 把打包这件事重新引回了开发环境，而且不是小优化，是把核心思路换了个方向。

什么叫「不打包」的开发服务器？就是你写代码的时候，Vite 不提前把你的项目打包成一个大文件，而是让浏览器直接加载你那些 ES Module。浏览器请求哪个模块，Vite 就当场转译哪个模块。这种方式的好处是冷启动快——不需要等打包完所有代码，浏览器直接就能跑起来。HMR 也快，因为改了一个文件，只需要重新加载那一个文件。

但这个模式有个天花板：模块数量多了以后，每次打开页面都要经历一遍「请求→解析→依赖→再请求」的链路，浏览器要发几十上百个 HTTP 请求，每个请求都有网络开销。千级模块还好，万级模块的时候，光请求队列就能等上十几秒。

Vite 8.1 的「打包开发模式」换了个思路：开发阶段也做打包，但不是用传统的方式。它在内存里打包，启动时先把所有模块聚合一次，然后以模块为粒度做热更新。这样浏览器第一次加载不再需要跑几十个请求，而是直接拿到打包好的结果。

Linear 有一个数据：切换到打包模式之后，大型项目的启动速度提升了 3 倍。注意这里说的是「有显著提升」而不是「快了 3 倍」，不同的项目规模数据会有差异，但方向是一致的。

这件事有意思的地方在于：它意味着 Vite 承认了「不打包」不是银弹。Vite 最早就是靠「不打包」这个差异点起来的，现在它把这个路又走了回去。这不是打脸，而是演进——当项目规模达到某个临界点，打包带来的初始化成本反而比网络开销更划算。

对前端团队来说，这个变化落地很直接：如果你现在 Vite 项目万级模块，冷启动要等十秒以上，试试开启打包模式，看实际效果再决定要不要切换。如果你的项目规模不大，传统模式仍然够用，没必要为了赶潮流加复杂度。

Vite 8.1 的打包模式目前还是可选的，默认行为没变。接下来几个版本如果数据稳定，它很可能变成大型项目的默认项。前端构建工具的核心思路正在经历一次重新校准——「不打包」和「打包」不是对错之争，是看场景选哪边更划算。