Webpack被Vite搞废了吗？我试了试真的回不去了

还记得吗？那种打开项目的时候，电脑风扇开始呜呜叫，你要么摸鱼，要么看会儿手机的感觉。

有人给这叫"Webpack启动仪式"——你做好了足够的心理建设，才敢npm run dev。

然后改个样式，又要等。改个组件，继续等。

等等等，等到最后连自己都麻了。

最气人的是什么？ 你的代码没问题，机器也没问题，就是Webpack非得在你面前演一场"整理所有文件"的把戏。把几百个文件扫一遍，解析依赖关系，转译这个，转译那个……最后才让你看到修改效果。

这年头谁还受这气呢？

直到有一天，我在新项目试了试Vite。

我按下回车键。

还没来得及拿起水杯——项目已经启动了。

真的。

转折来了，有个叫尤雨溪的人

尤雨溪（Evan You）是谁？Vue.js的作者。就是那个给React和Angular都造成过压力的哥们。

这哥们有一天看着Webpack，估计也是被折腾得不行了。他就想：凭什么非得我们干所有的活？浏览器这么聪明，为啥不让它自己加载文件？

这个想法听起来挺疯狂的。

但他没逃避，他干了。

2020年，Vite出现了。

如果说Webpack是"我全包了"，那Vite就是"我只干必要的活，其他的交给浏览器"。

听起来简单。

但这改变了一切。

vite vs webpack

vite vs webpack

核心差别就一句话，但得听懂

Webpack的做法： 你启动项目 → Webpack把所有文件都扫一遍 → 整理出"依赖关系图" → 全部编译成一个大Bundle → 最后才给你看效果

就像一个餐厅老板，顾客还没来呢，他就把所有食材都洗好切好，摆好了。客人来了不管点什么，都能立刻上菜——但这样做得多浪费啊。

Vite的做法： 你启动项目 → Vite起一个轻量级服务器 → 直接把你的源代码文件扔给浏览器 → 浏览器需要什么，就加载什么 → 用到的时候才临时编译

像是一个新派餐厅：顾客来了点菜，我现做。听起来会不会慢？

不会。 因为现做一个菜只需要30秒，但之前"全包"你得等5分钟。

关键是什么？浏览器原生支持ES Module啦。 这意味着浏览器自己就能去加载和执行JavaScript模块，不需要Webpack这个"中介"了。

速度差异到底有多大？我给你数据

拿我之前的一个项目来说：

用Webpack：npm run dev → 等45秒 → 项目启动 ✅

换成Vite：npm run dev → 等2秒 → 项目启动 ✅

改个样式：Webpack → 等8秒钟看到效果；Vite → 基本上改完就看到了

45秒 vs 2秒，这不是优化，这是质变。

而且这不是我瞎说的。现在有个数据是这样的：用Go语言写的编译工具（esbuild，Vite在用的），速度比用JavaScript写的工具（Babel，Webpack在用的）快10到100倍。

为啥？因为JavaScript要在Node.js里运行，要JIT编译，要预热……一堆折腾。而Go写的工具直接编译成二进制文件，就是快。

物理规律。 没办法。

还有个细节，改代码的时候那个爽劲

Webpack的热更新（HMR）听起来不错。实际用呢？经常出问题。

你改个代码，它可能：

• 状态丢失了
• 半天才更新
• 有时候干脆就不动

为啥？因为Webpack要重新编译一堆相关文件，然后重新打包，再做热更新。这个流程太长了。

Vite呢？改一个文件：

1. 编译这一个文件（毫秒级）
2. 通过WebSocket推给浏览器
3. 浏览器重新请求这个模块
4. 完事儿

全程：几十毫秒。 就那种"你还没抬起手指，页面已经更新了"的感觉。

我现在用Vite的时候，经常是改完代码直接看浏览器，都不需要按F5刷新。就那种感觉——用过一次就回不去了。

插件系统这块，Vite聪明在哪儿

Webpack那套插件系统，说实话，很难用。为什么？因为插件要理解整个Webpack的构建流程，钩子特别多，特别复杂。

你想给项目加个PWA功能（离线访问那种），得自己写插件或者找个库，配置还得一堆。

Vite就直接：

npm install vite-plugin-pwa

然后配置里加几行：

import { VitePWA } from 'vite-plugin-pwa'

export default {
  plugins: [VitePWA()]
}

完事儿。 PWA、service worker、离线缓存，全都有了。

这叫"最小化内核"。Vite的核心就干一件事儿，其他都交给插件。这样好处是什么？

生态爆炸式增长。

现在Vite有500多个插件。你想要什么功能，基本都有人写过。Vue、React、Svelte的集成？都是插件。PWA？插件。代码分析？插件。E2E测试？插件。

这哪儿像Webpack，什么都得自己捣鼓。

一个很实用的例子：代码分割

你做过这种需求吗？——某个功能用户不是每次都需要，比如"高级图表分析"或者"AI对话"。

用Webpack的话，你得手动写：

const HeavyComponent = () => 
  import(/* webpackChunkName: "heavy" */ './heavy')

然后Webpack就把这块打成一个独立的文件，大概200kb。

但这样还有个问题：Webpack怎么分割、分割多少，全是你得操心的事儿。

Vite就不一样了：

button.addEventListener('click', async () => {
  const { loadChart } = await import('./chart')
  loadChart()
})

完了。 不用注释，Vite自动检测到这个动态导入，自动给你切一个独立的chunk。用户点击按钮时才加载。

而且Vite切割得比Webpack激进——它会自动分析你的项目，把常用的库单独切出来，把不常用的打在一起，自动优化。

你根本不用操心。

现在有多夸张？

我看了下数据：

• 150万周下载（Vite）
• Vue用它（官方推荐）
• React官方也推荐用Vite
• Svelte、Solid、Astro全都以它为核心
• Laravel都用它
• Next.js的竞品SvelteKit、Nuxt，核心就是Vite

基本上，新项目不选Vite，你得有个好理由。

不是因为Webpack不行。Webpack依然能用，很多大项目也还在用。

但是——谁愿意继续忍受那45秒的启动时间呢？

说个现实的问题

你要是现在还在一个用Webpack的项目上，你是不是偶尔会想——为什么我们不切换到Vite呢？

我前阵子参加个线上会议，有个老哥直接说："我们的项目有200个modules，启动要1分钟。我试了试Vite，启动要6秒。"

1分钟 vs 6秒。

他后面就没再想别的了。

你要是这样的情况，迁移到Vite可能是性价比最高的优化。

但也得承认，Vite不是万能的。有些极端场景（比如超超大型项目，或者某些特殊的构建需求），Webpack可能还有存在的理由。

但这种场景真的很少了。

换个角度想

Webpack成功了这么多年，是因为它解决了一个真实的问题。当时浏览器不支持Module，Webpack就自己做了个方案。很牛逼。

但时间过去了。浏览器升级了，ESM标准出现了。

Vite的成功，本质上是因为它顺应了浏览器的进化。 不是去对抗浏览器，而是充分信任浏览器。

简单说：

• Webpack是"工具要做所有事儿"
• Vite是"工具只干必要的事儿，其他交给浏览器"

后者显然更符合时代。

最后的话

如果你现在正在一个Webpack项目上，改一次代码要等好几秒，那我的建议是：试试Vite。 真的，一个周末时间，说不定就切换过去了。

如果你正在开启一个新项目，还没想好用啥工具，那更简单了：就用Vite。 别想了。

反正现在大家都在用。文档齐全，社区活跃，插件一堆。

用过一次的人都说：再也回不去了。

你现在用的是啥？

评论区聊聊呗——Webpack还是Vite？如果是Webpack，是不是也被那启动速度折腾疯过？如果已经换了Vite，那我想听听你的迁移故事。