Vite 入门：新一代前端构建工具为什么更快

前端开发里，构建工具的存在感一直很低，直到它变慢的那一刻：改一行代码，页面要等好几秒才刷新；项目越做越大，第一次启动要等上一两分钟。Vite 出现之后，很多人第一次感受到，开发服务器原来可以几乎秒开，改动保存后页面几乎立刻更新。这篇文章就从一个初学者的角度，说清楚 Vite 为什么更快，以及它到底做了什么不一样的事。

一、传统构建工具为什么会慢

在 Vite 之前，主流做法是打包式开发。启动开发服务器之前，工具要先把整个项目里的模块一个一个找出来，解析它们之间的引用关系，再把它们打包成少数几个可以在浏览器里运行的文件。模块越多，这个过程就越慢，而且是改一次代码就要重新处理很多相关模块。

这种模式的另一个问题是，启动时就要处理全部代码，哪怕你当前只在看一个页面，用不到的其他页面和组件也会被一起处理。项目规模一上来，冷启动时间和热更新时间都会明显变长。

二、Vite 的核心思路：开发时不打包

Vite 最大的不同，是开发环境下不再先打包整个项目。它利用现代浏览器已经原生支持模块加载的特性，把源代码直接交给浏览器，让浏览器按需请求每一个模块。启动时只处理入口和当前页面真正需要的部分，其他模块等到被访问时再处理。

这样一来，启动速度就不再随着项目规模线性增长。项目里有一百个页面和有一千个页面，第一次打开的感受差别要小得多，因为用不到的代码根本不会在启动时被处理。

三、按需编译让热更新变快

保存代码后，Vite 只需要重新处理被改动的那个模块，以及少数与它直接相关的模块，而不是重新打包一大片代码。配合浏览器自带的模块缓存，没有改动的模块可以直接复用之前的结果。

对开发者来说，最直观的感受就是：改样式立刻见效，改逻辑几乎不用等。这种快不是心理作用，而是工作量本身变少了。

四、依赖预构建解决了一个老问题

很多第三方依赖在发布时仍然使用比较旧的模块格式，一个依赖内部可能包含成百上千个小文件。如果浏览器逐个请求它们，会产生大量网络请求，页面加载反而变慢。

Vite 在启动时会对这类依赖做一次预构建，把零散的文件合并成少数几个现代浏览器可以直接使用的模块，并做一次缓存。依赖没有变化时，下次启动就直接复用这份结果，既保留了按需加载的优点，又避免了请求数量爆炸。

五、生产构建依然走打包路线

需要注意的是，Vite 的快主要体现在开发体验上。真正上线部署时，它仍然会对代码做打包、压缩和优化，生成适合生产环境使用的文件。开发时不打包和生产时打包并不矛盾，前者是为了让写代码的过程更顺畅，后者是为了让用户打开页面更快、传输更少。

六、什么时候适合用 Vite

如果你在做一个现代前端项目，使用主流的前端框架，追求快的启动速度和热更新体验，Vite 是一个很自然的选择。它的配置相对简洁，默认行为已经能覆盖大多数常见场景，遇到特殊需求时再逐步调整。

当然，任何工具都有适用范围。一些历史比较久、结构比较特殊的老项目，迁移时需要先评估依赖和构建流程是否兼容，不要为了追新而盲目迁移。

结语

Vite 更快的本质，不是某一个黑科技，而是思路的改变：开发时只做必要的事，把工作量推迟到真正需要的时候，并把重复的工作缓存起来。理解了这一点，再去看它的各项功能，就不会觉得神秘。工具的意义始终是让开发者把时间花在业务本身，而不是花在等待构建上。