乐闻世界logo
5月31日 16:17

Vite 和 Webpack 该怎么选？

Vite 和 Webpack 的区别，不是“新工具淘汰旧工具”这么简单。Vite 开发阶段用原生 ESM 按需加载，生产阶段交给 Rollup 打包；Webpack 从一开始就围绕完整依赖图和打包体系设计。一个默认轻快，一个承载复杂工程多年积累，选择时要看项目边界。

开发阶段差异最大

Webpack dev server 通常要先分析入口、loader、plugin 和依赖图，项目越大，冷启动越慢。Vite 启动时先把服务器跑起来，浏览器请求哪个源码模块，再转换哪个模块；第三方依赖则通过 esbuild 预构建，减少 CommonJS 兼容和请求过多的问题。

这也是 Vite HMR 通常更快的原因。它更接近局部更新，而 Webpack 往往要重新编译受影响的模块集合。对页面多、源码多、定制不重的项目，这个差距非常明显。

生产构建各有优势

Vite 不是全程 esbuild，生产构建默认使用 Rollup。Rollup 在 ESM tree-shaking、库模式和产物结构控制上很成熟。Webpack 的优势则是复杂 loader、Module Federation、历史插件生态和高度定制能力。

ts
export default defineConfig({
  build: {
    target: 'es2020',
    rollupOptions: {
      output: { manualChunks: { vendor: ['react', 'react-dom'] } }
    }
  }
})

新项目、现代浏览器、Vue 3、React、Svelte、组件库文档和普通中后台，大多可以优先选 Vite。如果是多年老系统，依赖自定义 loader、旧浏览器兼容、私有构建平台或复杂微前端，Webpack 仍然可能是更稳的选择。

迁移时别硬翻译配置

迁移 Vite 最常见的坑有三类：CommonJS 和动态 require 处理不同；客户端环境变量要从 process.env 改成 import.meta.env；Webpack loader 和 Vite/Rollup 插件不是一一对应。不要把旧配置逐条翻译，很多配置在 Vite 里本来不需要。

ts
const api = import.meta.env.VITE_API_URL

更稳的迁移方式是从新页面、文档站、组件预览或独立子应用开始。先验证依赖、环境变量、部署和监控链路，再决定是否扩大范围。

追问

Vite 一定比 Webpack 快吗？

开发冷启动和 HMR 上，Vite 通常更快，尤其是现代前端项目。生产构建不一定，取决于压缩器、插件、依赖体积和分包策略。Webpack 如果用了持久化缓存和 SWC/esbuild loader，也可能表现不错。边界是不要拿空模板 benchmark 替真实项目做决定。

老项目适合直接迁到 Vite 吗？

不一定。老项目常有隐藏构建逻辑，比如自定义 loader、全局变量、polyfill 和特殊别名。直接迁移可能主流程正常，边缘页面或灰度环境才出问题。更稳的取舍是先迁低风险模块，再扩大范围。

生产包体积谁更小？

没有绝对答案。Vite 借助 Rollup 的 ESM tree-shaking，Webpack 也有 splitChunks、sideEffects 和成熟插件。包体积更多取决于依赖写法、是否按需加载、是否引入大而全的库。常见坑是换工具前不清依赖，让构建工具背锅。

微前端场景选哪个？

如果重度依赖 Module Federation，Webpack 仍然更成熟。Vite 也有相关插件，但在共享依赖、版本协商和遗留系统接入上要更谨慎。取舍是成熟稳定还是开发速度。核心交易系统不要为了工具升级牺牲可预测性。

团队熟悉 Webpack，还值得换吗？

如果启动和 HMR 已经明显拖慢效率，值得小范围试点。Vite 配置心智更轻，但团队仍要理解 ESM、Rollup 和环境变量差异。迁移成本还包括 CI、部署、监控和文档更新。不要只让一个人迁完，否则后续没人维护。

标签：Vite