在 Rolldown 集成前,Vite 的 Dev/Build 分治架构由两套独立工具驱动,二者技术栈、数据模型、调度逻辑完全隔离,产生不可规避的性能与一致性损耗。
传统架构完整执行链路
- 开发环境 Dev基于 Go 编写的 Esbuild 执行依赖预构建,扫描 node_modules 生成扁平 ESM 缓存,浏览器按需请求模块;模块热更新依赖 Node.js 层文件监听、AST 重解析。
- 生产环境 Build基于 JS 编写的 Rollup 完成全量模块图构建、Tree-Shaking、代码分块、产物打包;需要完整重新扫描项目依赖、解析源码、重建模块图,无法复用 Dev 阶段任何中间产物。
四大核心不可解缺陷
重复消耗 IO 与 CPU。Esbuild、Rollup 拥有两套独立的词法/语法解析器,Dev、Build 阶段会完整重复读取源码、解析 AST、遍历依赖图谱。万文件项目下,两次全量解析带来成倍磁盘 IO、字符串处理开销,冷启动与全量构建耗时叠加。
跨语言调用调度损耗严重。Esbuild 为 Go 二进制,通过 Node.js 子进程 IPC 与 Vite 通信;Rollup 纯 JS 运行在主线程。二者调度模型不互通,文件读取、模块转换、插件执行无法并行调度,主线程频繁阻塞,多 CPU 核心资源无法充分利用。
一致性维护成本极高。Dev 预构建使用 Esbuild 插件,Build 打包使用 Rollup 插件,同一业务转换逻辑(TS 转译、CSS 处理、资源内联)需要维护两套插件实现,极易出现「开发正常、构建报错」的环境不一致问题,大幅提升大型项目维护成本。
Tree-Shaking 收益受限。Esbuild 仅做扁平依赖打包,不具备精细化模块连接优化;Rollup 的 Tree-Shaking 基于 JS 单线程遍历,无法利用多核并行标记死代码。两套工具均无法实现全链路并行符号分析,大型库、多页面项目摇树效率偏低。