Vite 8 + Rolldown 一统天下，webpack 的时代真的过去了

yugu88
0 阅读12分钟

目录

  • 01 webpack 为什么走到了终局
  • 02 Vite 8 + Rolldown 到底快在哪
  • 03 从 webpack 迁移到 Vite 8 的 5 步实录
  • 04 性能对比：数据说话
  • 05 前端构建工具的终局猜想

上个月我把一个 Vue 3 项目从 webpack 迁移到 Vite 8。构建时间从 47 秒变成了 1.8 秒。我盯着终端发了两分钟呆——不是因为慢，是因为我以为它还没开始跑，结果它已经跑完了。这个项目有 1400 多个模块、三套路由、两个微前端子应用，webpack 构建一次够我泡一杯咖啡。而 Rolldown——这个用 Rust 重写的 Rollup 替代品——直接把「等构建」这件事从我的工作流里删除了。Vite 8 把 Rolldown 作为默认打包器正式集成，这不是小版本迭代，这是前端构建工具十年来最大的一次换代。

我不是在写软文。我只是一个被 webpack.config.js 折磨了六年的普通前端，终于在 2026 年感受到了「构建」这件事本该有的样子。

01 webpack 为什么走到了终局

我 2020 年入行时，webpack 是「前端工程化」的代名词。面试官问你会不会 webpack，等于在问你是不是正经前端。那时候所有人的 webpack.config.js 都是从上一个项目复制过来的，没人真正搞懂那 200 行配置每一行在干什么。

webpack 的问题不是某一个点坏了，是整个架构在 2026 年已经不合时宜。

第一，Bundle 疲劳。 webpack 的核心逻辑是把所有模块打成一个（或几个）bundle。项目小的时候无所谓，项目大了以后，每次构建都要把几千个文件重新分析依赖、转译、合并。这就像你每次出门都要把整栋楼的锁全检查一遍——理论上更安全，实际上没人受得了。我那个项目 1400 多个模块，webpack 每次冷启动分析依赖树就要 12 秒，这 12 秒纯粹在做「理解你的代码」这件事，一行产出都没有。

第二，配置地狱。 我去年帮一个朋友看他的 webpack 配置，他的项目只有 23 个页面，但 webpack.config.js 写了 387 行。loader 链套了 5 层，plugin 注册了 11 个，光一个 CSS 提取就用了 MiniCssExtractPlugin + css-loader + postcss-loader + sass-loader 四件套。更恐怖的是，其中有三个 loader 的版本互相冲突，升一个就挂两个。这不是工程化，这是地雷阵。

第三，Rust 工具链的碾压。 2024 年开始，前端工具链进入了「Rust 重写一切」的时代。esbuild 用 Go 证明了 JavaScript 构建可以快 100 倍，SWC 用 Rust 替代了 Babel，Biome 用 Rust 替代了 ESLint + Prettier。webpack 是纯 JavaScript 写的，它的性能天花板就是 V8 的天花板。当 Rolldown 用 Rust 把 Rollup 的全部功能重写一遍，并且兼容了 webpack 的大部分插件生态，webpack 的最后一张牌——生态——也被翻了。

⚠️ 如果你现在还在维护一个超过 200 行的 webpack.config.js，你大概率能理解那种「改一行配置祈祷十分钟」的感觉。不是 webpack 不好，是它承载的东西太多，多到自己也扛不住了。

💬 评论区聊聊：你现在用什么构建工具？

A. webpack（老项目没法换） B. Vite（已经迁过来了） C. Turbopack（跟着 Next.js 走） D. Rspack（字节系全家桶）

02 Vite 8 + Rolldown 到底快在哪

先说结论：Vite 8 的生产构建速度是 webpack 5 的 20-30 倍，开发环境 HMR 是毫秒级。 这不是营销数据，是我在自己项目上实测的。

要理解这个速度差，得拆开看三个层面。

第一层：Rust 原生编译速度。 Rolldown 是用 Rust 从零写的。Rust 编译出来的是原生机器码，直接跑在 CPU 上，没有 V8 的 JIT 编译开销，没有垃圾回收暂停，没有 JavaScript 的动态类型检查。同样是解析一个 1MB 的 JS 文件，Rolldown 比 Rollup 快 10 倍以上。更关键的是，Rust 天生支持多线程并行——Rolldown 在解析依赖树的时候，可以同时用 8 个核跑 8 个文件，而 webpack 只能单线程串行（是的，thread-loader 只解决了转译并行，依赖分析依然是单线程）。

第二层：Tree-shaking 大幅增强。 webpack 的 Tree-shaking 一直是「理论上很美好，实际上很保守」。遇到副作用标注不清的包，webpack 宁可多打也不敢少打。Rolldown 继承了 Rollup 的 Tree-shaking 算法——这是业界公认最精准的——同时用 Rust 的性能做了更深层的作用域分析。我那个 Vue 3 项目，最终产物从 webpack 的 312KB 降到了 Vite 8 + Rolldown 的 247KB。同样的代码，少了 20% 的体积，不是因为我改了什么业务逻辑，纯粹是 Rolldown 更聪明地剔除了死代码。

第三层：开发环境的原生 ESM + 智能预构建。 Vite 从 1.0 开始就用浏览器原生 ES Module 做开发环境，省掉了打包这一步。但之前有个痛点：第三方依赖（node_modules）需要预构建成 ESM 格式，这一步是用 esbuild 做的，虽然快但存在兼容性问题。Vite 8 换成了 Rolldown 来做预构建，好处是开发和生产用的是同一套引擎——再也不会出现「开发没问题上线就炸」的灵异事件。HMR 速度依然是毫秒级，改一行代码，浏览器几乎是同步更新的。

Vite 8 最大的突破不是「更快」，而是「统一」——开发和生产终于用同一个引擎了。Dev 和 Prod 的行为一致性，是前端工程化十年来最大的未解之痛。Rolldown 一次性治好了。

还有一点很多人没注意到：Vite 8 的 Environment API。这是 Vite 6 引入的能力，在 Vite 8 中正式成熟。你可以在同一个 Vite 项目中定义多个构建环境——比如 client、SSR server、edge worker——每个环境有独立的模块图、插件管线和构建策略。这在 webpack 里需要维护三份配置文件，在 Vite 8 里是一个 vite.config.ts 搞定。

03 迁移实录：从 webpack 到 Vite 8 的 5 步

理论讲完了，来讲实操。我把自己迁移的完整过程记录下来，你可以直接照着做。项目背景：Vue 3.5 + TypeScript + Vue Router + Pinia + Vant 4，原来用 webpack 5 + vue-cli 5。

Step 1 — 换依赖

删掉 webpack 全家桶，装 Vite 8。听起来吓人，其实就几行命令。

# 删除 webpack 相关依赖
npm remove webpack webpack-cli webpack-dev-server
npm remove css-loader style-loader sass-loader
npm remove html-webpack-plugin mini-css-extract-plugin

# 安装 Vite 8
npm install -D vite@^8.0.0 @vitejs/plugin-vue

我删掉了 14 个 webpack 相关的 devDependencies，换成了 2 个。package.json 少了 47 行。

Step 2 — 写 vite.config.ts

webpack.config.js 387 行 → vite.config.ts 38 行。不是我偷懒省略了什么，是 Vite 真的不需要那些配置。

// vite.config.ts
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  resolve: {
    alias: { '@': '/src' }
  },
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
})

Sass？Vite 内置支持，不需要 loader。PostCSS？Vite 自动读取 postcss.config.js。HTML 模板？项目根目录放一个 index.html 就行。

Step 3 — 环境变量迁移

这是最容易踩坑的一步。webpack 用 process.env.VUE_APP_XXX，Vite 用 import.meta.env.VITE_XXX。

# .env 文件改名
VUE_APP_API_URL → VITE_API_URL

# 代码里全局替换
process.env.VUE_APP_ → import.meta.env.VITE_

我用 VS Code 全局搜索替换，一共改了 23 处。注意：只有 VITE_ 前缀的变量才会暴露给客户端，这是安全设计。

Step 4 — 处理 require() 和 CommonJS

Vite 是 ESM-first 的。如果你的代码里有 require()，需要改成 import。

// ❌ webpack 时代的写法
const img = require('@/assets/logo.png')

// ✅ Vite 的写法
import img from '@/assets/logo.png'

// 动态导入也没问题
const module = await import(`./pages/${name}.vue`)

我这个项目有 8 处 require()，全是图片资源引用。5 分钟改完。如果你的项目 require 特别多，可以用 vite-plugin-commonjs 做过渡。

Step 5 — CI/CD 改 scripts

最后一步，改 package.json 的 scripts 和 CI 配置。

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

CI 的构建命令从 npm run build 不变，产出目录从 dist/ 也不变。GitHub Actions 那边我只改了一行 Node 版本要求（Vite 8 需要 Node 20+）。

值得截图保存 —— webpack → Vite 8 迁移清单（5 步）：

  1. 删 webpack 依赖，装 vite + @vitejs/plugin-vue
  2. 把 webpack.config.js 改写成 vite.config.ts
  3. 环境变量 VUE_APP_ → VITE_
  4. require() → import，CommonJS → ESM
  5. 改 scripts，CI 确认 Node 20+

总耗时：约 2 小时（含测试回归）

💬 迁移到 Vite 最难的是什么？

A. 配置改写（loader 对应关系搞不清） B. 插件兼容（webpack 插件没有 Vite 替代品） C. 老板不让动（能跑就不要碰） D. 没什么难的，半天搞定

04 性能对比：数据说话

以下数据全部来自我的实测项目（Vue 3.5 + 1467 modules），测试机器是 MacBook Pro M3 Max 36GB，每项跑 5 次取中位数。

指标webpack 5Vite 8 + Rolldown提升
冷启动（dev）28.3s0.4s70x
生产构建47.1s1.8s26x
HMR 更新1200ms18ms67x
产物体积（gzip）98.7 KB78.9 KB-20%
构建内存峰值1.4 GB320 MB-77%
配置文件行数387 行38 行-90%

几个数据值得单独说。

冷启动 70 倍差距，是因为 Vite 的开发服务器根本不打包——它直接用原生 ESM 把模块按需送给浏览器。webpack 必须在启动时把整个依赖树分析完、编译完才能提供服务。Rolldown 负责的预构建（把 node_modules 的 CJS 包转成 ESM）在第一次之后会缓存，所以再次启动几乎是瞬间。

HMR 18ms，这个数字意味着什么？意味着你按下 Ctrl+S 的手指还没松开，浏览器已经更新了。webpack 的 1200ms 不只是慢，它慢到你会下意识去刷新页面——这就破坏了 HMR 存在的意义。

内存占用 320MB vs 1.4GB，这对 CI/CD 影响巨大。我们团队用 GitHub Actions，每个 runner 只有 7GB 内存。以前构建大项目时偶尔会 OOM，换成 Vite 8 后这个问题直接消失了。如果你用的是按量计费的 CI（比如 AWS CodeBuild），内存减少意味着直接省钱。

构建工具的好坏不看跑分，看它有没有从你的开发流程中「消失」。最好的构建工具是你感知不到它存在的那个。Vite 8 + Rolldown 做到了。

顺便提一下竞品对比。Turbopack（Vercel 出品，绑定 Next.js 生态）在 Next.js 项目里确实很快，但它不是通用工具，你不能拿它去构建一个 Vue 项目。Rspack（字节跳动出品）走的是「兼容 webpack API」路线，对老项目迁移最友好，但它的理念是修补 webpack 而不是替代它。Vite 8 + Rolldown 的独特之处是：它不兼容 webpack，它直接给了你一个更好的东西。

05 前端构建工具的终局猜想

我不觉得 webpack 会「死掉」。jQuery 到现在还有 77% 的网站在用，webpack 的存量项目比 jQuery 还多。那些几百万行代码的企业级巨无霸——银行系统、电商中后台、政务平台——可能未来十年都不会迁移。这很正常，能跑就不要动，这是工程师的生存本能。

但所有新项目，我看不到任何理由再选 webpack。

Vite 8 + Rolldown 的组合意味着：你不需要在「开发体验」和「生产可靠性」之间做选择了。 以前用 Vite 4/5 的时候，开发环境用 esbuild，生产用 Rollup，两套引擎行为不一致会偶尔出幺蛾子。现在全链路都是 Rolldown，这个痛点彻底消失了。

我对前端构建工具终局的判断是三足鼎立：

Vite + Rolldown 吃掉大部分通用场景（Vue、React、Svelte、纯 TS 库），成为事实标准。Turbopack 在 Next.js 生态内独占一方，Vercel 生态的项目别无选择。Rspack 成为 webpack 老项目的救星，字节系和不想大改的团队会选它。

而 webpack 本身？它会像 Grunt 一样——没有人宣布它死了，但也没有人在新项目里用了。它会慢慢从招聘 JD 里消失，从面试题库里退役，从技术博客的标题里淡出。不是死了，是退休了。

⚠️ 对我个人来说，迁移到 Vite 8 之后最大的变化不是构建速度——虽然那确实很爽——而是我不再恐惧碰构建配置了。以前改 webpack.config.js 的心情跟拆炸弹差不多，现在 vite.config.ts 清清楚楚三十几行，改哪里一目了然。这种「不怕碰工具链」的感觉，比跑分提升更有价值。

如果你还在犹豫要不要迁移，我的建议是：先在一个小项目上试。 把你手头最小的那个项目花两小时迁过去，跑一遍构建，看看那个数字。体验过 1.8 秒的构建之后，你不会想回去的。

Rolldown 项目的 Slogan 是「The Rust bundler for JavaScript」。但我觉得更准确的说法是：这是前端构建工具的终局形态——快到你感知不到它存在。

💬 最后一个问题：你觉得 webpack 还能撑多久？

A. 已经死了（新项目没人用了） B. 1-2 年（等存量项目迁移完） C. 3-5 年（企业级项目没那么快动） D. 永远不会死（jQuery 至今还活着呢）

下篇预告

下一篇我会写**「AI 辅助编程的真实产出数据」**——我用 Claude Code 写了一个月的代码，记录了每天的 token 消耗、代码行数、Bug 率。到底 AI 写的代码质量行不行？数据说话。

关注「AI 创业 100 天」系列，不错过下一篇。

AI 创业 100 天 · 往期精选

  • 第 1 篇：提示词工程与上下文工程
  • 第 2 篇：别再装 Skill 了
  • 第 3 篇：我给 AI 接了 17 个 MCP
  • 第 4 篇：Opus 4.7 + Routines 接了 231 个工具
  • 第 5 篇：我卸了 Cursor，代码产出反而翻了 3 倍
  • 第 10 篇：Vite 8 + Rolldown 一统天下（本篇）
avatar
文章
阅读
粉丝