很多人升级 Vite 8 时只记住一句话——换成了 Rust 写的 Rolldown更快了。但更快到底快在哪、和原来用的 esbuild、Rollup 又是什么关系很少有人说清。我手工搭了三份结构相同、规模递增的依赖图把 esbuild、Rollup、Rolldown 三台引擎拉到同一基准下各跑一遍结果树摇三家都是 100% 满分真正的差距落在构建时间上最大差出 4 倍多。背景为什么 Vite 8 换引擎这件事值得测Vite 在 8 之前是一个双引擎架构开发态用 esbuild 做依赖预打包生产构建却交给 Rollup。两套解析、两套插件模型最难受的是开发与生产行为不完全对齐——本地没问题上线包却不一样大。2026 年 Vite 8 把生产打包也切到 RolldownRust 实现的 Rollup API 兼容打包器目标就是开发和生产用同一台引擎。但共识归共识落到自己项目上还是三个问题新引擎树摇有没有 Rollup 那么干净和 esbuild 比到底谁快规模变大后差距是收敛还是放大不实测这些都只是文档里的形容词。解剖esbuild / Rollup / Rolldown 到底是什么关系三者不是三代产品而是三种定位不同的打包器恰好被 Vite 在不同阶段用过esbuildGo 写的全能选手bundle minify一条龙速度极快是 Vite 开发态预打包的主力。RollupJS 写的老牌库打包器以树摇最干净著称是 Vite ≤7 的生产引擎。RolldownRust 写、API 对齐 Rollup目标是Rollup 的树摇质量 接近 esbuild 的速度直接成了 Vite 8 的统一引擎。一句话区别以前 Vite 是 esbuild快但不兜底生产配 Rollup稳但慢现在 Rolldown 想一个人把两件事都干了。图1左为 Vite ≤7 的双引擎——开发与生产分属两套解析存在行为对齐缺口右为 Vite 8 统一到 Rolldown 单引擎开发与生产同源。实证同一份依赖图三台引擎跑一遍我没有拿别人仓库跑分而是自己生成了无副作用的纯函数 barrel依赖图保证树摇难度一致、可复现N 个模块每个导出 8 个纯函数返回各自唯一的字符串标记UZ_xxx_yyy一个index.js用export *把所有模块聚成 barrel入口只 import 其中 4 个函数并打印其余数千个导出理论上应被全部消除。死代码有没有被消除用一个笨但可靠的办法验证扫描产物里残留的UZ_标记数量。只要某个没被用到的函数标记还留在产物里就说明没摇干净。依赖图导出总数esbuildRollupRolldown树摇三家120×8 扁平9609.71 ms21.76 ms6.53 ms100%600×8 扁平480033.23 ms103.20 ms24.75 ms100%480×8 两级 barrel384031.09 ms67.81 ms15.86 ms100%把构建总时间画成柱状图更直观——每台引擎一根三组图并排图2颜色越亮越快。Rolldown蓝在每一组都最短Rollup红随规模膨胀最明显。换算成加速比更扎心Rolldown vs Rollup3.3× → 4.2× → 4.3×两级 barrel 下最大Rolldown vs esbuild1.5× → 1.3× → 2.0×两级 barrel 下差距反而拉大。注意第三组是两级export *的深层 barrel——esbuild 和 Rollup 的时间都上去了Rolldown 却几乎没涨。说明Rolldown 对 re-export 链路的处理更跟手规模越复杂它的相对优势越明显。图3左为被测依赖图的解剖绝大多数导出应被消除右为结论卡——树摇三家满分构建时间差出 4 倍以上Rolldown 始终在最左。复现把这份 benchmark 跑起来环境Node 22、esbuild 0.28.1、rollup 4.62.4、rolldown 1.2.1。核心逻辑就三步——生成图、分别打包、统计残留标记# 1. 装三台引擎同目录 npm i esbuild0.28.1 rollup rolldown 2. 生成依赖图N 个模块 × 每模块 8 个纯函数index.js 用 export * 汇聚 入口只 import 4 个函数其余应在产物中消失 3. 三台引擎各自打包minify 统一交给 esbuild.transform保证体积对比公平 node -e const esbuildrequire(esbuild),rolluprequire(rollup),{rolldown}require(rolldown); // ... 见仓库 run.jsbuildEsbuild / buildRollup / buildRolldown 三个函数 4. 统计产物里残留的 UZ_ 标记数 —— 0 即树摇满分 grep -o UZ_[0-9]_[0-9] dist/out.js | sort -u | wc -l完整可跑脚本含三种规模的循环与中值取平均见文末开源地址。构建时间取预热一次后两次平均minify 对三者统一用 esbuild避免不同压缩器干扰时序对比。局限这次实测没覆盖什么诚实地说这是一组受控、干净的 ESM 图它证明了现代引擎对纯函数 barrel 的树摇都已做到满分但没回答另一些更现实的问题带副作用的模块一旦模块顶层有副作用写全局、注册监听三家都会保守保留差异不在摇不摇得掉而在副作用分析是否误伤——本实验未涉及。CJS 互操作大量老库仍是 CommonJSesbuild 与 rollup/rolldown 的commonjs插件策略不同树摇表现可能反转需要单独一局。真实业务图 ≠ 纯函数图组件、CSS、动态 import 会引入本实验没有的边结论需回到你自己的vite build --mode production里再验一次。所以这篇不是 Rollup 该退休了而是在干净 ESM 上树摇已是基础设施级能力Vite 8 把引擎统一后你失去的是双引擎的 parity 风险换来的是 Rolldown 这一档的速度。结论与下一步一句话方法论别再把 tree-shaking 当选型门槛——esbuild、Rollup、Rolldown 对干净 ESM 都是 100%真正要盯的是构建时间与开发/生产一致性而 Rolldown 恰好把这两项一起补上了。升级 Vite 8 时与其担心树摇会不会变差不如直接在自己项目上vite build跑一遍时间对比。开源地址矩阵门户GitHub - wangzifan396-wzf/WB: nano-tools: 400 single-file, zero-dependency, local-first web utilities in one portal. Offline and private, nothing leaves your browser. Binary protocol parsers, crypto, dev, audio, visualization, productivity. · GitHub单文件工具聚合器https://github.com/wangzifan396-wzf/nano-workbenchGitHub 组织主页https://github.com/wangzifan396-wzf 树摇三家都满分，构建却差出 4 倍：Vite 8 换引擎的实测复盘
很多人升级 Vite 8 时只记住一句话——换成了 Rust 写的 Rolldown更快了。但更快到底快在哪、和原来用的 esbuild、Rollup 又是什么关系很少有人说清。我手工搭了三份结构相同、规模递增的依赖图把 esbuild、Rollup、Rolldown 三台引擎拉到同一基准下各跑一遍结果树摇三家都是 100% 满分真正的差距落在构建时间上最大差出 4 倍多。背景为什么 Vite 8 换引擎这件事值得测Vite 在 8 之前是一个双引擎架构开发态用 esbuild 做依赖预打包生产构建却交给 Rollup。两套解析、两套插件模型最难受的是开发与生产行为不完全对齐——本地没问题上线包却不一样大。2026 年 Vite 8 把生产打包也切到 RolldownRust 实现的 Rollup API 兼容打包器目标就是开发和生产用同一台引擎。但共识归共识落到自己项目上还是三个问题新引擎树摇有没有 Rollup 那么干净和 esbuild 比到底谁快规模变大后差距是收敛还是放大不实测这些都只是文档里的形容词。解剖esbuild / Rollup / Rolldown 到底是什么关系三者不是三代产品而是三种定位不同的打包器恰好被 Vite 在不同阶段用过esbuildGo 写的全能选手bundle minify一条龙速度极快是 Vite 开发态预打包的主力。RollupJS 写的老牌库打包器以树摇最干净著称是 Vite ≤7 的生产引擎。RolldownRust 写、API 对齐 Rollup目标是Rollup 的树摇质量 接近 esbuild 的速度直接成了 Vite 8 的统一引擎。一句话区别以前 Vite 是 esbuild快但不兜底生产配 Rollup稳但慢现在 Rolldown 想一个人把两件事都干了。图1左为 Vite ≤7 的双引擎——开发与生产分属两套解析存在行为对齐缺口右为 Vite 8 统一到 Rolldown 单引擎开发与生产同源。实证同一份依赖图三台引擎跑一遍我没有拿别人仓库跑分而是自己生成了无副作用的纯函数 barrel依赖图保证树摇难度一致、可复现N 个模块每个导出 8 个纯函数返回各自唯一的字符串标记UZ_xxx_yyy一个index.js用export *把所有模块聚成 barrel入口只 import 其中 4 个函数并打印其余数千个导出理论上应被全部消除。死代码有没有被消除用一个笨但可靠的办法验证扫描产物里残留的UZ_标记数量。只要某个没被用到的函数标记还留在产物里就说明没摇干净。依赖图导出总数esbuildRollupRolldown树摇三家120×8 扁平9609.71 ms21.76 ms6.53 ms100%600×8 扁平480033.23 ms103.20 ms24.75 ms100%480×8 两级 barrel384031.09 ms67.81 ms15.86 ms100%把构建总时间画成柱状图更直观——每台引擎一根三组图并排图2颜色越亮越快。Rolldown蓝在每一组都最短Rollup红随规模膨胀最明显。换算成加速比更扎心Rolldown vs Rollup3.3× → 4.2× → 4.3×两级 barrel 下最大Rolldown vs esbuild1.5× → 1.3× → 2.0×两级 barrel 下差距反而拉大。注意第三组是两级export *的深层 barrel——esbuild 和 Rollup 的时间都上去了Rolldown 却几乎没涨。说明Rolldown 对 re-export 链路的处理更跟手规模越复杂它的相对优势越明显。图3左为被测依赖图的解剖绝大多数导出应被消除右为结论卡——树摇三家满分构建时间差出 4 倍以上Rolldown 始终在最左。复现把这份 benchmark 跑起来环境Node 22、esbuild 0.28.1、rollup 4.62.4、rolldown 1.2.1。核心逻辑就三步——生成图、分别打包、统计残留标记# 1. 装三台引擎同目录 npm i esbuild0.28.1 rollup rolldown 2. 生成依赖图N 个模块 × 每模块 8 个纯函数index.js 用 export * 汇聚 入口只 import 4 个函数其余应在产物中消失 3. 三台引擎各自打包minify 统一交给 esbuild.transform保证体积对比公平 node -e const esbuildrequire(esbuild),rolluprequire(rollup),{rolldown}require(rolldown); // ... 见仓库 run.jsbuildEsbuild / buildRollup / buildRolldown 三个函数 4. 统计产物里残留的 UZ_ 标记数 —— 0 即树摇满分 grep -o UZ_[0-9]_[0-9] dist/out.js | sort -u | wc -l完整可跑脚本含三种规模的循环与中值取平均见文末开源地址。构建时间取预热一次后两次平均minify 对三者统一用 esbuild避免不同压缩器干扰时序对比。局限这次实测没覆盖什么诚实地说这是一组受控、干净的 ESM 图它证明了现代引擎对纯函数 barrel 的树摇都已做到满分但没回答另一些更现实的问题带副作用的模块一旦模块顶层有副作用写全局、注册监听三家都会保守保留差异不在摇不摇得掉而在副作用分析是否误伤——本实验未涉及。CJS 互操作大量老库仍是 CommonJSesbuild 与 rollup/rolldown 的commonjs插件策略不同树摇表现可能反转需要单独一局。真实业务图 ≠ 纯函数图组件、CSS、动态 import 会引入本实验没有的边结论需回到你自己的vite build --mode production里再验一次。所以这篇不是 Rollup 该退休了而是在干净 ESM 上树摇已是基础设施级能力Vite 8 把引擎统一后你失去的是双引擎的 parity 风险换来的是 Rolldown 这一档的速度。结论与下一步一句话方法论别再把 tree-shaking 当选型门槛——esbuild、Rollup、Rolldown 对干净 ESM 都是 100%真正要盯的是构建时间与开发/生产一致性而 Rolldown 恰好把这两项一起补上了。升级 Vite 8 时与其担心树摇会不会变差不如直接在自己项目上vite build跑一遍时间对比。开源地址矩阵门户GitHub - wangzifan396-wzf/WB: nano-tools: 400 single-file, zero-dependency, local-first web utilities in one portal. Offline and private, nothing leaves your browser. Binary protocol parsers, crypto, dev, audio, visualization, productivity. · GitHub单文件工具聚合器https://github.com/wangzifan396-wzf/nano-workbenchGitHub 组织主页https://github.com/wangzifan396-wzf