有朋友从老项目切到 Vite跑完 dev server 之后第一句话是这也太快了。冷启动从二十多秒变成一秒出头保存文件后基本秒刷。他问我为什么差距这么大我说了一句当时听着有点绕的话因为 Vite 在开发模式下压根没有“打包”而 Webpack 从入场第一秒起就在为整个依赖图打包。这句差别其实才是 Webpack 与 Vite 所有分歧的总源头。这篇内容我会从底层机制、开发体验、生产构建、迁移坑位和选型判断五个角度拆开讲面向的是手头项目正纠结“要不要迁 Vite”的前端工程师也适合刚接触工程化、想弄明白两个构建器到底在干什么的人。核心原则是不要被“快”字带着走先把背后的取舍搞清楚再决定动不动的刀。1. 一切分歧的源头Webpack 把所有模块揉成一团Vite 选择不揉1.1 Webpack 的“打包”生命周期从入口到产物所有模块都得先过一遍Webpack 的工作机制可以简化成一句话从你指定的 entry 出发递归地把所有通过 import、require 引用的模块找出来生成一个完整的模块依赖图然后对这些模块做转换、合并、分包最后输出成浏览器能识别的静态文件。这个过程在webpack serve启动时就要基本走完一遍哪怕你只是在本地开发浏览器还没打开Webpack 也得先把整个项目的模块图构建好。一个最小 Webpack 配置通常会是这样// webpack.config.js const path require(path); module.exports { entry: ./src/index.js, output: { filename: bundle.js, path: path.resolve(__dirname, dist), }, module: { rules: [ { test: /\.js$/, use: babel-loader }, ], }, devServer: { hot: true, }, };这段配置背后Webpack 要处理的事情比表面上复杂得多。每个.js文件都要经过 loader 的处理链Babel 要做语法转换ts-loader 要编译 TypeScriptcss-loader 要处理样式里的依赖关系。所有的编译结果会先写进内存里的文件系统再通过 dev server 以 bundle 的形式提供给浏览器。问题就出在这里模块图越大启动时需要转换的模块就越多。一个四五千个组件的中型后台项目冷启动要等服务端把所有模块编译完十几秒甚至二十几秒是很常见的事。这也催生了一堆 Webpack 打包优化配置比如cache: { type: filesystem }持久化缓存、thread-loader 多线程转译、把 Babel 换成 SWC 等。这些优化本质上都是在和同一个宿命对抗不管怎么优化你必须先把所有模块处理一遍浏览器才能跑起来。1.2 Vite 的开发服务器用浏览器原生 ESM按需处理源文件Vite 的开发模式选择了一条完全不同的路。浏览器原生支持script typemodule已经很长时间了项目里写的import语句可以直接被浏览器识别。Vite 的开发服务器不把这些 import 合并成一个 bundle而是保留模块原本的引用关系让浏览器自己去按需发请求加载模块。当一个请求打到 Vite 服务器时它只对当前这个文件做转换比如把.vue单文件组件编译成 JS或者把.ts文件里的类型信息剥掉转换完直接返回给浏览器。别的模块没人请求它就什么都不做。这就是“点啥做啥”的按需转译模式。// vite.config.js import { defineConfig } from vite; import vue from vitejs/plugin-vue; export default defineConfig({ plugins: [vue()], server: { port: 5173, open: true, }, });一个很反直觉的点是Vite 并不是完全不预构建它会把项目的第三方依赖用 esbuild 预先打成一个缓存包放在node_modules/.vite/deps目录下。原因也好理解一个项目的 dependencies 里动辄几百个 npm 包如果用原生 ESM 一个包一个包地发请求光建立连接就够受的。业务代码可以等请求来了再按需转译依赖这种稳定不变的模块则提前转成 ESM 并发缓存下次启动直接命中。所以我常跟同事打一个比方Webpack 开发模式像是厨师在开餐前把所有菜装进盒子备好客人一来就能端上桌但出餐时间取决于你备了多少道菜Vite 则是后厨先把酱料、半成品预制到位客人点一道菜就做一道大部分时候你感觉不到等待。1.3 生产构建为什么 Vite 也要“打包”了到这里可能有读者产生一个疑问既然原生 ESM 这么好为什么 Vite 生产构建不直接把源码原样给浏览器还要用 Rollup 再打包一遍答案是性能。上线之后的资源文件是要走网络加载的源码里动辄几百个模块让浏览器一个接一个地发请求HTTP/2 下虽然能缓解一部分并发问题但整体加载性能依然远不如把代码合理地合并、压缩、分包。更关键的是tree shaking、资源指纹、chunk 缓存这些优化离线打包才能做得彻底。所以 Vite 采用的是一条双引擎策略开发环境用 esbuild 做按需转译和预构建生产环境用 Rollup 做完整的打包优化。这里要记住一点也正是因为开发和生产用的是两套引擎实际项目里偶尔会遇到同一个模块在 dev 下正常、build 出问题的情况。它不像 Webpack 一样一套编译管线走到底这是 Vite 双引擎设计天然的另一面代价。2. 冷启动与热更新两种机制的响应差距随着项目规模被放大2.1 esbuild 预构建为什么第一次启动 Vite 会显示 Pre-bundling dependencies用 Vite 跑一个新项目第一次启动时控制台会提示Pre-bundling dependencies过一会儿才会进入等待页面。这个预热过程其实就是在做依赖预构建。esbuild 是 Go 语言写的打包器转译能力非常强悍。Vite 会把node_modules下的依赖对准入口看哪些是页面里真实引用到的然后用 esbuild 把它们合并成几个 ESM 文件统一缓存起来。这样浏览器请求依赖的时候只需要加载少数的预构建文件而不是对着某一个大 npm 包展开几十个小请求。这里有个隐藏的好处源代码和依赖代码在 Vite 里是分开处理的依赖几乎不变预构建缓存一直有效源码变了只影响被请求到的那个模块。而 Webpack 开发时业务模块和第三方包都在同一个模块图里任何一个文件的改动都可能导致整个依赖图被重新评估虽然有了持久化缓存后有所缓解但模块之间的联动仍然是 Webpack HMR 的核心性能瓶颈。预构建缓存需要更新的时候也不少。比如你改了 package.json或者上升了依赖版本Vite 会自动重新预构建再比如依赖里有动态 import 的写法有时预构建抓不准就要手动用optimizeDeps.include把它圈进来。这类坑后面迁移章节我会专门展开。2.2 HMR 链路差异Webpack 重编译依赖子图Vite 只失效被改模块热更新是开发体验里感知最强烈的一环。Webpack 的 HMR 链路大致是文件修改后Webpack 监听文件系统变化重新编译受影响的模块及其依赖子图编译完通过 WebSocket 把一段更新后的模块代码推给浏览器由运行时决定如何替换页面里的模块。模块图的规模决定了一轮 HMR 的耗时所以项目一大保存一次文件经过两三秒、三四秒才刷新都是家常便饭还会有复杂依赖链被整段打翻的情况。Vite 的 HMR 链路则更接近“精准手术”。它以原生 ESM 的模块边界为单位做失效判断一个文件被修改Vite 会对该模块以及直接依赖它的模块链做一次失效然后通过 WebSocket 通知浏览器拉取这个模块的新版本。其余没有被影响的模块完全不动因此热更新时间几乎和项目总量没什么关系基本稳定在几十毫秒量级。举个实际场景一个三千多组件的大型后台某个公共工具函数被几十个页面引用。Webpack 遇到这种情况保存一个文件可能要把这几十个引用它的页面全部重新编译推送Vite 则只更新这个工具函数模块本身并且利用import.meta.hot.accept的边界控制做到页面不整体刷新。这种体验差异不经过一次大项目迁移是感受不完全的。2.3 规模拐点在哪里我的实测体感单说数据容易引起争论还是用我这两年在普通开发机上的体感来讲。一千模块以下的小项目Webpack 冷启动大概三四秒Vite 也有一秒多两边感受都还行差距没那么刺眼。项目走到四五千模块之后量变产生质变Webpack 冷启动干到十几秒很常见HMR 在一到两秒之间抖动Vite 冷启动依然是一两秒HMR 基本在 50 毫秒内。我自己的心理分水岭是 5000 个模块左右。到了这个量级Webpack 的每个保存操作都像在等待一个微型部署任务开发节奏会被明显拖慢Vite 的即时响应让人更敢频繁地改代码验证效果。这里也顺带提醒一句Vite 开发服务器的资源占用不一定比 Webpack 低它只是把时间成本挪到了按需处理上如果机器配置很老大规模项目下内存占用未必占优。3. 生产构建的岔路口树摇与拆包的实现思路各自带了取舍3.1 tree shakingRollup 更“贪心”Webpack 要你配合生产构建里最常被拿出来对比的就是 tree shaking。Webpack 的 tree shaking 依赖 ES Module 的静态结构需要在mode: production下自然开启并且理想情况 package.json 里有sideEffects: false标记代码里不要用 CommonJS 写导出。Babel 配置要是把模块语法转成了 CommonJS那 tree shaking 当场就废了所以很多老项目还得专门加一层modules: false的设定。Rollup 的 tree shaking 从设计上就更激进它会顺着模块里的引用关系逐层分析能把一个组件里根本没被引用的工具函数、常量直接删除掉。Vite 的生产构建基于 Rollup天然继承了这一点。有测试过同一个 React 项目切换到 Vite 构建后产物体积经常能缩小 10% 到 30%主要就是 Rollup 对未使用代码的清除更彻底。不过我不建议把这个当成迁移的唯一理由因为 webpack 配合 sideEffects 与正确的模块化写法效果也不会差太远。真正的区别更多在边界能力上Rollup 对同一个文件里未导出的代码、分支里的死代码清理得更细腻Webpack 更依赖人为标记能力不一定不够而是大多数项目没做到位。3.2 拆包策略splitChunks 与 manualChunks 的取舍拆包这件事两边思路差异也挺大。Webpack 的optimization.splitChunks是开箱即用的强大分包方案它会对依赖图里的公共模块做自动分析把第三方库和公共依赖拆成独立的缓存 chunk默认策略几乎不需要配置就能获得不错的效果。大量开发者的难点反而在于配置规则太复杂一个splitChunks对象能写出一百多行。Vite 生产构建时默认行为比较保守它会保留入口下按需 import 的动态模块分割但对第三方依赖不会像 Webpack 那样主动做精细的公共 chunk 拆分。想要手动控制就得在build.rollupOptions.output.manualChunks里写函数build: { rollupOptions: { output: { manualChunks(id) { if (id.includes(node_modules)) { if (id.includes(lodash) || id.includes(xlsx)) return vendor-utils; if (id.includes(react)) return vendor-react; return vendor; } }, }, }, },这段函数的逻辑很直白把第三方依赖按名字归并到几个 vendor chunk 里。它的优点是产物结构完全可控缺点是把拆包规则交还给了开发者一个没注意还会出现循环依赖告警。我在实际迁移中吃过这个亏所以给一个建议如果项目对缓存策略没有极致诉求先用 Vite 的默认拆包跑一轮再按首屏资源瀑布图决定要不要 manualChunks别一上来就手术式拆包。3.3 兼容性底线你手头的用户能不能接受 Vite 的默认产物Vite 的默认构建目标定在现代浏览器它产的 JS 基本不做语法降级import、动态 import、顶层 await 这些特性被称为 baseline。如果用户群体里还有大量旧版系统浏览器这一条就可能直接劝退你。这时候就必须上vitejs/plugin-legacy它会额外生成一份 legacy bundle并配合 polyfill 在旧环境里兜底。但代价也很实在产物多出一份旧代码文件浏览器加载的总体积明显变大现代浏览器还得做一次降级判断。相比 Webpack 只要把output.target配置降一下就能针对特定浏览器产出形态更可靠的代码兼容处理的顺滑度确实是 Webpack 的老成持重之处。我看到过不少项目停在 Webpack 不是因为它慢而是因为不敢动兼容性这个下限。比如某些政企环境、银行内网、教育机构等用户的浏览器版本不由前端团队说了算。这种场景下 Vite 的“快”没有意义稳定不出错才是第一优先级。4. 迁移时最容易翻车的几个点从 xlsx-style 到环境变量再到插件适配4.1 base 与静态资源路径部署子路径直接开天窗从 Webpack 迁到 Vite首先要面对的是资源路径语义变化。Webpack 里你习惯配置output.publicPathVite 里对应的叫base。差别在于 Vite 要求base必须以/结尾而且默认是/如果你的部署目录是二级路径比如挂在域名下的/admin/下就得显式设置base: /admin/。更隐蔽的是public目录的引用方式。Vite 的public目录里的静态资源在源码里必须用绝对路径/xxx.png引用而不是./xxx.png。我从 Webpack 迁移时项目里一堆require(../../public/logo.png)的写法到了 Vite 下全部变成请求失败。这种问题在本地开发环境往往看不出来部署到服务器后才发现 logo、favicon 一片灰。建议迁移前先做一次静态资源引用的全局扫描把public下的资源改用绝对路径把url-loader、file-loader的资源导入改成 Vite 的?url方式。别看这些都是小问题它们是最容易在验收时被甲方直接截图的。4.2 xlsx-style 这类历史依赖为什么一言不合就报错开头提到有一个热搜词叫“vite 使用 xlsx-style”说明这不是我一个人踩过的坑。xlsx-style 是一个老牌的 Excel 导出样式库但它底层依赖cptable、fs、os这些 Node.js 模块而且包装方式是 CommonJS。Webpack 经过 node polyfill 和 loader 处理勉强能在浏览器里把这串依赖链编译过去到了 Vite 的预构建机制里这类依赖直接成了重灾区。实际报错通常有这么几种“global is not defined”“cptable is not defined”“Cannot read properties of undefined”以及 import 之后模块整体为空。原因不完全是 Vite 不支持 CJS而是它默认只处理真正被 import 到的依赖对这类带着 Node 内建模块的库esbuild 预构建后的运行时环境未必完整。这类问题有几个处理方向按优先级排列第一如果能换库直接换掉比如xlsx-js-style是社区维护的 forkREADME 里就支持样式导入ESM 适配也做得干净我在新项目里已经彻底不用 xlsx-style 了。第二如果项目不能换库就需要在 vite.config 里显式圈定依赖并补一个 polyfill 入口optimizeDeps: { include: [xlsx-style], },但这还不够运行时可能还得在入口文件里做简单垫片window.global window; window.process { env: {} };实际项目中我推荐把思路从“硬撑旧库”转到“更换底座”上来。因为旧库往往停更多年即使这次用 polyfill 绕过去了后续新浏览器版本一变问题还会复发。前一个项目里我们就是从 xlsx-style 换到 xlsx-js-style 后导出样式功能完全对齐反而少了一大段兼容代码。4.3 server.open 在 Linux 上翻车xdg-open 与无桌面环境的坑另外一个热搜词“vite xdg-open”估计不少人遇到的是同一个画面在 Linux 服务器或者 WSL 环境下启动 Vite终端突然冒出一堆关于 xdg-open 的报错有时还会触发浏览器拉起失败dev server 进程直接卡住。Vite 的server.open默认是 false但有些脚手架会帮你打开浏览器在 Linux 环境下它通过 xdg-open 命令去调用系统默认浏览器如果运行环境没有桌面会话或者 WSL 里联动 Windows 浏览器的配置没做好就会翻车。我的做法很简单本地开发时主动设置server.open: false需要看页面就自己手动在浏览器输入地址自动化脚本或者 CI 跑测试时更不要把 open 打开因为服务端环境根本不需要也不应该拉起图形程序。如果你确定本地想自动打开可以在配置里写成open: true并检查系统里xdg-open是否可用。另外还有vite preview这个命令也藏着一个类似的坑很多人喜欢在部署验证时跑preview再带着--open参数结果在没有浏览器的环境里整个进程异常退出。正常做法是只运行vite preview --host然后通过 curl 探活验证静态服务是否正常。4.4 环境变量与 require.context一批 Webpack 专属 API 要换写法迁移 Vite 时代码层面最频繁的改动来自环境变量。Webpack 里习惯用process.env.NODE_ENV和 DefinePlugin 注入的全局变量Vite 则统一走import.meta.env.VITE_XXX的形式所有带VITE_前缀的环境变量会从.env文件注入。如果你项目里到处写着process.env.xxx迁移时先做一个全局搜索把相关引用整理出来。其中process.env.NODE_ENV在 Vite 里可以用import.meta.env.DEV和import.meta.env.PROD替代语义更清晰。再看动态批量导入。Webpack 的require.context是一个很顺手的功能Vite 没有这个 API替代品是import.meta.glob。比如一个后台项目要自动加载所有views目录下的页面模块Vite 下可以这样写const modules import.meta.glob(./views/*.vue); for (const path in modules) { const loader modules[path]; routes.push({ path: getRoutePath(path), component: loader }); }第一版import.meta.glob返回异步 loader依赖懒加载场景正好符合如果想像require.context一样立即导入用import.meta.globEager或现在新版本里的import.meta.glob(path, { eager: true })。这类 API 替换不复杂麻烦的是数量多一个成熟项目里可能有几十处建议迁移前用编译报错和 grep 排两轮。5. 别被“快”绑架这些场景下 Webpack 依然是稳的选择5.1 微前端与模块联邦Webpack 5 自己有专属舞台Vite 不是任何时候都该上的。微前端是其中一个典型场景特别是 Webpack 5 的 Module Federation。它允许不同子应用在运行时共享部分代码主应用能远程加载子应用暴露的模块中间的 shareScope、remote 配置都是 Webpack 内建的运行时能力。社区里确实有 vite-plugin-federation 这种方案可以实现类似的共享能力但它本质上是在 Vite 的后端模拟 Webpack federation 的协议遇到版本升级、边界 case 时稳定性会比内置实现差不少。如果你的微前端基座已经基于 Webpack 5 搭建而且多个子应用之间有大量的共享依赖调度我建议保持 Webpack不要为了开发模式那几秒的启动速度去动整个运行时基础。5.2 Next.js 这类框架把 Webpack 内嵌了别想着单独抽出来再延伸到框架层面。Next.js 默认的构建工具链就是 WebpackTurbopack 作为下一代打包器目前仍处于实验阶段。也就是说使用 Next.js 时你基本没有太多“换成 Vite”的自由空间框架层的路由、图片优化、Server Components 渲染都和打包器深度耦合。而 Nuxt 3 这类框架默认选择 Vite走的是另一条路线。这引出一个选型常识框架锁定了构建器的时候不要绕开框架去硬换。非要强行塞一个 Vite等于同时失去了框架的默认优化能力和生态兼容。同样的道理放在老项目里也一样一个项目里深度用了一堆 Webpack 插件、自定义 loader、内部编译层的约定换 Vite 意味着这些东西要么重写要么找替代成本可能远超收益。5.3 选型判断矩阵什么项目用 Vite什么项目留在 Webpack项目类型推荐构建器核心理由全新中后台、管理端Vite开发体验好生态够用默认基线已覆盖绝大多数内部系统老项目、运行稳定且痛点不大Webpack迁移成本高收益有限别为了快而制造回归风险深度使用模块联邦的微前端Webpack 5共享运行时更成熟协议兼容性更稳用户群体包含大量旧浏览器Webpack低版本 target 兼容链路成熟可靠框架内嵌打包器Next.js 等跟随框架默认强行更换等于放弃框架级优化大型 monorepo、多包协同视情况包多多说明生态成熟度高但也要求 Vite 对 monorepo 依赖处理做一轮试跑这张表是我实际判断项目时的基准不是标准答案但它足够帮你避免最糟糕的决策把一个运行良好的老 Webpack 项目为了追求新鲜感搬到 Vite结果发现问题比想象的要多。我自己的结论其实有点朴素新项目我无脑 Vite这没什么可纠结的存量 Webpack 项目只要没有明确的性能痛点就不动刀真要迁先建一个 demo 分支并行跑一两周把开发启动、生产构建、产物体积、回归测试数据全部拉出来对比。有一次我们迁移一个接近百万行代码的存量系统构建产物突然出现了两个在 Webpack 下从未见过的循环依赖告警排查花了一整周这让我深刻意识到迁移的隐性成本有时候比显性收益更难量化。你问我 Webpack 和 Vite 的区别我会说清楚机制上的每一点不同但落到团队决策时我会补一句工具是拿来用的不是拿来换的先想明白项目到底需要解决什么问题再决定迁移这把刀要不要落下。