接手这个运维后台构建项目时我看到的 commit message 几乎都是“改一行重新编译 2 分钟”。团队开会时有人提出“干脆换 Vite 吧”但项目里还有上百个依赖老 webpack 插件的模块不可能一夜之间推翻。真正做下来我才发现所谓“webpack Vite”并不是一个二选一的非此即彼而是一条双轨并跑、渐进迁移的路线用 Vite 的 dev server 解决开发体验让 webpack 继续守住一部分历史产物和回归基线。这篇文章就是把我这次的迁移思路、关键配置、踩过的坑以及最终选型判断框架一次性讲清楚适合正在为构建速度焦虑、却又无法立刻重写脚手架的团队做参考。1. 为什么“webpack Vite”不是二选一一次构建升级的真实起点1.1 团队的真实痛点往往不是“构建工具过时”先说背景。这个项目是一个典型的中后台系统几十个路由页面累计上千个组件webpack 版本不算新但也没有到不可用的程度。团队成员最直接的感觉是冷启动要 60 秒以上保存一次代码热更新要 3 到 5 秒CI 上全量构建经常跑到 5 分钟开外。于是有人提议换 Vite理由是“网上都说 Vite 快几十倍”。这个理由不假但一开始就走了偏路。因为我们把问题定义成了“要不要换工具”而真正的问题是“开发链路里的哪一段最耗时以及我们有没有能力把这一段的成本降下来”。把 webpack 换成 Vite能解决的只是 dev server 启动和 HMR 的体验如果 CI 上的生产构建、老模块的兼容性、自定义插件的维护成本没有一并考虑迁移最终会变成一场灾难。所以我提倡的是“先测量再迁移”。我把开发时的启动耗时拆成四个环节依赖解析、代码转译、模块打包、浏览器刷新。webpack 在 dev 模式下的设计是“先全量打包再交给浏览器”所以依赖解析和模块打包在启动阶段就是一次性的巨大开销。Vite 则完全换了一套逻辑开发阶段不让 webpack 参与打包而是利用浏览器原生 ESM让浏览器自己去请求模块Vite 只负责按需转译和依赖预构建。这就是两者开发体验差距巨大的根因也是我们迁移计划的核心依据。1.2 把“构建快”拆成两种完全不同的语义我们团队最开始争论不休的一个点是到底用“构建速度”还是“开发体验”来评价工具。后来我意识到这两个维度分别对应 dev 和 build 两条链路必须独立看。在 dev 链路里Vite 几乎必然赢得开发者的好感。原因在于浏览器原生 ESM 天然具备“按需加载”能力你访问哪个页面浏览器才去请求那个页面用到的模块插件和工具类模块则大多被 Vite 预先合并成少数几个缓存文件。启动时不需要把整个项目的依赖图全部编译一遍自然就能做到秒级启动。但到了 build 链路Vite 实际上是交给底层的 Rollup 来完成打包大量代码分割、压缩、兼容处理仍然需要和 webpack 一样按模块图走一遍。如果项目本身巨大且没有做合理的缓存策略Vite 的 build 未必比 webpack 快多少。所以“换 Vite 之后一切都会变快”这个认知在大型存量项目里是不准确的。这也是为什么标题里的“webpack Vite”更贴近实践的真相开发阶段用 Vite生产构建继续沿用 webpack或者至少要保留 webpack 作为回归对照。等我们对 Vite 这条新链路有了足够的掌控力再逐步把生产构建也切过去风险才能被控制住。2. 拆开“快”字模块打包、依赖预缓存与 HMR 在两条路线里的本质差异2.1 模块视角webpack 是全量图Vite 是浏览器驱动的按需图如果只记一个结论我建议记这句话webpack 把浏览器当成“最终消费者”自己在服务端把所有模块打包成链路再交付Vite 把浏览器当成“运行时协作者”由浏览器主动请求模块Vite 只做中间翻译。webpack 的模块图构建过程大致是从入口文件开始通过 loader 转译文件内容解析 import/require逐层收集依赖最终形成一张完整的依赖图再按规则拆成 chunk写入到 dev server 的内存中。浏览器的每个请求拿到的都是已经打包好的资源。这套模型的好处是稳定、可控大量自定义 loader 和插件可以深度介入打包过程坏处就是冷启动慢项目越大启动时一次性开销越大。Vite 的模型则完全不同。开发时它不会把项目代码打包成 chunk而是把每个源文件映射成一个 ESM 模块地址浏览器请求哪个文件Vite 才对该文件进行即时转译。打个比方webpack 像一个在饭前就准备好整桌菜、按菜单分盘上桌的大厨Vite 则像按客人需求现场炒菜的开放式厨房客人报一个菜名厨师做一道做完了再问下一位。这种差异在项目规模变大的时候尤其明显。一个有着几十个路由、三四百个页面级组件的项目webpack 冷启动时的全量模块图构建时间会随着依赖树增长而线性甚至超线性上升Vite 的按需机制则让启动时间跟“当前页面实际请求了多少模块”有关而不是跟“整个项目有多少模块”有关。这也是我们从开发侧切入迁移的第一个原因。2.2 依赖预构建Vite 的缓存策略与 webpack 的持久化缓存策略很多人以为 Vite 快只是因为不打包其实还有一个容易被忽略的点依赖预构建。node_modules 里的第三方依赖尤其是那些以 CommonJS 格式发布的旧包直接交给浏览器 ESM 环境跑会有问题。Vite 的做法是在首次启动时扫描依赖入口用 esbuild 把这些依赖预打包成 ESM 格式并存放到 node_modules/.vite 目录下。esbuild 本身是用 Go 写的转译速度比传统 JS 链路的工具快一到两个数量级所以首次预构建虽然也要花点时间但比 webpack 的完整打包快得多。预构建结果会被缓存。只要你的依赖列表没有变化后续启动直接读缓存。这对开发场景特别友好第一次启动可能要等十几秒第二次基本就是秒开。我在迁移过程中还特意确认了 cacheDir 的配置位置因为某些 CI 环境会把 node_modules 当作临时目录每次重装后缓存被清掉Vite 就得重新预构建。后续我们在 CI 的缓存策略里单独保留了 .vite 目录才把重复启动的耗时压了下去。webpack 也有一套自己的 caching 机制比如持久化缓存filesystem cache。它会把模块转译结果、chunk 生成结果以序列化格式写入文件系统下次构建时优先复用。它和 Vite 的预构建缓存各有各的适用范围webpack 的缓存覆盖整个构建图包括业务源码和 loader 输出Vite 的缓存更多是面向第三方依赖。所以如果你在 webpack 里已经开好了持久化缓存生产构建的耗时并不一定比 Vite 差太多。判断工具优劣不能只看默认配置下的“第一感觉”。2.3 HMR 与生产构建两套链路要分开评估HMR热更新是另一个“快得感受明显”的环节。webpack 的 HMR 也是从模块图里找到变更模块再让浏览器执行更新逻辑但因为它要先完成对变更模块的依赖图更新计算项目大了之后热更新计算本身也会拖慢。Vite 的 HMR 则基于原生 ESM编辑一个文件后Vite 只向浏览器推送该模块的更新浏览器重新请求这个模块地址即可路径天然比 webpack 更短。我实测过同一个老页面的改动。原来 webpack 热更新平均 3 秒左右切到 Vite 之后基本在 300 到 600 毫秒。这个差距不是配置技巧可以抹平的而是模型层面的差异。所以如果团队最痛的是“改代码后等待时间太长”把开发链路切到 Vite 是性价比最高的方案。但生产构建不能照搬这个逻辑。Vite 的 build 默认由 Rollup 执行Rollup 在处理大型业务项目时也有自己的脾气比如它的默认分块策略、tree-shaking 效果、CSS 代码分割行为和 webpack 不一定一致。同样的项目webpack 可能打出几个很合理的公共包Rollup 可能打出多个小碎块或者在循环依赖、动态 import 拆包上表现不同。因此我建议把“生产构建”和“开发构建”当成两个独立问题来决策不要因为 dev server 跑得飞快就顺理成章地把生产构建也切过去。3. 双轨并跑的迁移路线Vite 开发热更 webpack 产物回归的共存方案3.1 迁移的第一步不是重写项目而是让两套构建进程并存我们当时的策略可以概括为开发上线用 Vite回归验证继续用 webpack。具体做法是先搭一个独立的 Vite dev server跑在固定端口并把接口请求、静态资源路径代理到已有的开发环境。业务代码先不做任何改动能跑通多少算多少。听起来很保守但这是最稳妥的切入方式。原因很简单存量项目里通常藏着大量隐性依赖比如 webpack 配置里定义了全局变量、别名、样式注入、自定义 loader这些东西不会自动适配 Vite。如果一上来就全量迁移报错数量会大到让人直接放弃。双轨并跑的意义在于团队成员可以先在 Vite 下享受快速热更同时随时切回 webpack 环境查看产物差异逐步把不兼容的地方一个个修掉。具体落地时我会先处理三类基础问题路径别名、环境变量注入、静态资源引用。路径别名改动影响范围最大因为业务代码里可能大量使用了一段固定路径前缀在 webpack 里通过 resolve.alias 指向某个目录在 Vite 里需要改成 vite-tsconfig-paths 或手动配置 resolve.alias。我们在迁移时先把 tsconfig 里的 paths 与 vite 的 alias 统一起来让两套配置指向同一份目录映射避免维护两套路径表。3.2 从“能跑”到“跑得稳”代码改造的优先级清单双轨跑通之后我们才开始按优先级改造业务代码。清单如下顺序是按“影响面大但收益也大”排的清除隐含的全局变量依赖。webpack 的 DefinePlugin 和 ProvidePlugin 在 Vite 里都有替代方案但不能默默照搬。区域配置里的全局变量可以通过 Vite 的 define 配置注入但那些依赖全局函数的代码最好改成显式的 import避免迁移后模块化边界不清。迁移样式预处理器的注入配置。老项目经常会在 scss/less 里注入全局变量、mixin 文件webpack loader 有额外参数Vite 里则通过 css.preprocessorOptions 配置。这一步要特别小心因为全局样式变量被注入后每个样式文件编译出来的结果可能不同差异排查很费时。处理第三方依赖的兼容层。部分老包依赖 Node 内建模块webpack 5 之前会自动注入 polyfillVite 默认不会。我们需要按需给这些包配置 alias 或添加 polyfill 脚本而不是全局引入一大坨兼容层。调整静态资源的访问方式。webpack 里 publicPath 和 file-loader/url-loader 的规则比较复杂Vite 则以 assetsInclude、base 配置替代。迁移时要把图片、字体等资源的相对路径和打包后的路径统一起来。验证动态 import 的路由分割。Vue 或 React 项目里大量使用动态 import 做路由懒加载Vite 对这类语法的处理基本兼容但分包数量可能不同。要在 build 阶段看产物差异避免出现某个页面包异常变大。当时我们按这个顺序改了两周Vite dev server 已经完全能支撑日常开发webpack 生产构建则一直保留作为发版基线。这段时间里日常开发效率明显提升但并没有立刻取消 webpack因为还要等一次完整回归来确认 Vite 不会引入兼容性问题。3.3 推荐的共存配置一份可以抄作业的骨架如果你也想双轨并跑可以直接参考我整理的最小配置骨架。项目保留 webpack.config.js 不动新增 vite.config.ts核心内容大致如下// vite.config.ts 最小共存配置示例 import { defineConfig } from vite; import vue from vitejs/plugin-vue; import path from path; export default defineConfig({ plugins: [vue()], resolve: { alias: { : path.resolve(__dirname, src), // 与老项目的 webpack alias 保持一致 }, }, server: { port: 5173, proxy: { /api: { target: process.env.API_TARGET || http://localhost:8080, changeOrigin: true, }, }, }, css: { preprocessorOptions: { scss: { additionalData: use /styles/variables.scss as *;, }, }, }, define: { // 注意define 里只能是可序列化的字符串或值 __APP_ENV__: JSON.stringify(process.env.APP_ENV || dev), }, });对应的 webpack.config.js 保持原样只在脚本 release 里增加一个回归构建命令。这样团队日常开发跑 Vite发布前跑 webpack build 做验证两套链路互不干扰。等到 Vite build 出来的产物在多次回归里都稳定了再考虑把发布脚本切到 Vite。4. 迁移之后才暴露的兼容性断层副作用文件、Node 内建与分包策略4.1 副作用模块一个容易让 tree-shaking 误伤的隐蔽问题双轨并跑期间我们遇到了几个典型问题第一个就跟模块副作用相关。webpack 在生产构建时会根据 package.json 里的 sideEffects 字段做 tree-shakingVite 底层交给 Rollup 时也有一套自己的判断。但问题在于某些第三方依赖的 sideEffects 字段声明并不准确明明会修改全局对象或注册自定义样式却被标记成了无副作用。这种包在 webpack 下可能因为模块图遍历方式不同而侥幸保留到了 Vite 就被错误地摇掉了。我当时排查一个老项目里的图表库现象是页面能打开但图表不渲染控制台只有一句“xxx is not a function”。最终定位到是某个工具包内部注册了全局扩展方法但因为 sideEffects 标记错误被 Rollup 在 build 时剪掉了。解决方式有两个一是在 package.json 里显式声明引入该文件二是用 Vite 的 optimizeDeps.include 强制预构建。如果你在迁移后碰到“某第三方功能在 dev 正常、build 消失”第一反应就去看 sideEffects。4.2 Node 内建模块Vite 不会替你默默做 polyfillwebpack 5 之前官方默认给浏览器环境注入 Node 核心模块的 polyfill所以很多老代码依赖 process、Buffer、path 这类模块也能跑。但 Vite 专门面向浏览器不会主动做这类兼容迁移后首当其冲的就是用到了 process.env 和 Buffer 的包。我们项目里就有两个历史工具函数用了 process.env.NODE_ENV 判断环境还有一个小型上传模块引了 Buffer。Vite dev 阶段因为浏览器环境可能自带部分兼容问题不明显build 阶段直接报错 module not found。处理办法分两步自己能控制的业务代码全部改成显式判断环境变量第三方依赖有这种问题就通过 resolve.alias 指向一个新的 polyfill 文件或者用社区维护的 polyfill 包按需注入。注意不要全量引入几十个 polyfill那只会白白增加产物体积。4.3 分包策略不一致Rollup 的默认行为未必符合业务预期第三个坑是 chunk 划分的差异。webpack 的 splitChunks 可以精细控制公共模块、node_modules 依赖、异步页面的分块策略Rollup 也有 manualChunks但默认行为更“轻”容易出现大量零碎小 chunk或者公共依赖被打进不同页面 chunk 导致重复加载。我当时用 Vite build 跑了一遍全量产物发现 vendor 包被打成了好几个小文件项目里几个大页面各自引了重复的工具方法整体体积比 webpack 版本多了将近 10%。后来在 vite.config.ts 里通过 build.rollupOptions.output.manualChunks 手动聚拢了高频依赖才把体积降下来。这一段没有通用秘诀得看自己项目里哪些依赖被多个页面复用。建议先跑一次分析报告再决定聚合规则。迁移后产物体积异常往往就是这一步没做而不是 Vite 本身膨胀。4.4 环境变量与浏览器兼容定向注入别一把梭最后说一下环境变量的注入差异。webpack 里 DefinePlugin 的写法是直接把整段文本替换成代码片段所以你可以把 JSON.stringify(process.env.X) 写进配置。Vite 的 define 配置同样做文本替换但更推荐使用 import.meta.env 的统一形式。迁移时我把老代码里的 process.env.XXX 都搜了一遍逐个改成 import.meta.env.XXX 或显式注入的常量。浏览器兼容层面Vite 默认构建目标是基于原生 ESM 的浏览器版本如果你的系统需要支持较旧浏览器记得设置 build.target并配合 autoprefixer 补全 CSS 前缀。我们因为只面向内网办公环境这个压力不大但如果你的产品面向外部客户这一步不能省略。5. 哪一种场景仍该留守 webpack面向团队与工程的选型判断表5.1 判断框架用“生态控制力”而不是“跑分”做决策聊到这里你可能会问既然双轨跑得通那是不是所有项目都该换 Vite我的答案是不一定。选型的关键不是看某个工具在 benchmark 里快多少而是看团队对构建链路的“控制力”。所谓控制力就是你遇到问题的时候能不能快速定位、修改、稳定复现解决方案。webpack 的优势在于插件生态悠久几乎所有历史遗留的怪问题都有人踩过Vite 的插件体系更年轻但已经覆盖了绝大多数日常需求。如果你团队的构建配置里塞了大量内部自定义 loader、自研插件或者依赖 webpack 严重的 loader 顺序和钩子机制那么强行迁到 Vite 可能要把这些自定义逻辑整个重写一遍成本远超收益。我见过一个反例一个维护了三四年的老系统webpack 配置足有一千多行里面有自研的国际化资源抽取插件、自定义文件指纹规则、特定 loader 链。团队花了三周试图迁移到 Vite最后因为自研插件无法平滑适配而回滚了。这类场景下最实际的优化不是换工具而是先清理老的 webpack 配置去掉无效 loader 和重复插件再开启持久化缓存把构建耗时降下来。工具切换是手段不是目的。5.2 一张粗糙但实用的选型表为了方便决策我把项目类型和推荐策略列成了一张表你可以直接拿自己的项目去对照项目画像推荐方案理由新项目没有历史包袱团队人数少直接用 Vite热更新体验好配置轻插件足以满足常见需求老项目webpack 配置复杂团队经验集中在 webpack保留 webpack先做配置瘦身和持久化缓存避免迁移风险收益也足够老项目代码量大但配置相对标准痛点集中在 cold start 和 HMR双轨并跑dev 用 Vitebuild 保留 webpack开发体验收益最大回归风险最小老项目且对生产构建体积、分包策略有严格指标谨慎迁移先对比产物Rollup 分包策略与 webpack 不同需要专门调优团队准备长期迭代愿意投入时间维护构建链路渐进迁移至 Vite长期收益更高开发与构建体验统一这张表不是标准答案但它能帮你快速分清自己手里的牌。我在团队的最终决定是开发环境全面切换 Vite生产构建暂时保留 webpack用一个半月的时间做回归对比再决定是否切换 build 链路。事实证明这个节奏让团队既能享受即时反馈又不会在关键发版前夜被构建问题拖住。最后想分享一个个人经验不要因为 Vite 的 dev server 快就默认它的 build 也快也不要因为 webpack 冷启动慢就否定它对复杂构建场景的掌控力。构建工具是工程土壤换土之前先看看根系扎得多深。与其把所有筹码押在某个“更时髦”的工具上不如让旧工具和新工具在项目里短暂共存用真实数据决定下一步。哪怕最终你选择完全不换工具这段“对比着用”的过程也会让你对自己项目的构建链路理解得更透彻。
接手这个运维后台构建项目时我看到的 commit message 几乎都是“改一行重新编译 2 分钟”。团队开会时有人提出“干脆换 Vite 吧”但项目里还有上百个依赖老 webpack 插件的模块不可能一夜之间推翻。真正做下来我才发现所谓“webpack Vite”并不是一个二选一的非此即彼而是一条双轨并跑、渐进迁移的路线用 Vite 的 dev server 解决开发体验让 webpack 继续守住一部分历史产物和回归基线。这篇文章就是把我这次的迁移思路、关键配置、踩过的坑以及最终选型判断框架一次性讲清楚适合正在为构建速度焦虑、却又无法立刻重写脚手架的团队做参考。1. 为什么“webpack Vite”不是二选一一次构建升级的真实起点1.1 团队的真实痛点往往不是“构建工具过时”先说背景。这个项目是一个典型的中后台系统几十个路由页面累计上千个组件webpack 版本不算新但也没有到不可用的程度。团队成员最直接的感觉是冷启动要 60 秒以上保存一次代码热更新要 3 到 5 秒CI 上全量构建经常跑到 5 分钟开外。于是有人提议换 Vite理由是“网上都说 Vite 快几十倍”。这个理由不假但一开始就走了偏路。因为我们把问题定义成了“要不要换工具”而真正的问题是“开发链路里的哪一段最耗时以及我们有没有能力把这一段的成本降下来”。把 webpack 换成 Vite能解决的只是 dev server 启动和 HMR 的体验如果 CI 上的生产构建、老模块的兼容性、自定义插件的维护成本没有一并考虑迁移最终会变成一场灾难。所以我提倡的是“先测量再迁移”。我把开发时的启动耗时拆成四个环节依赖解析、代码转译、模块打包、浏览器刷新。webpack 在 dev 模式下的设计是“先全量打包再交给浏览器”所以依赖解析和模块打包在启动阶段就是一次性的巨大开销。Vite 则完全换了一套逻辑开发阶段不让 webpack 参与打包而是利用浏览器原生 ESM让浏览器自己去请求模块Vite 只负责按需转译和依赖预构建。这就是两者开发体验差距巨大的根因也是我们迁移计划的核心依据。1.2 把“构建快”拆成两种完全不同的语义我们团队最开始争论不休的一个点是到底用“构建速度”还是“开发体验”来评价工具。后来我意识到这两个维度分别对应 dev 和 build 两条链路必须独立看。在 dev 链路里Vite 几乎必然赢得开发者的好感。原因在于浏览器原生 ESM 天然具备“按需加载”能力你访问哪个页面浏览器才去请求那个页面用到的模块插件和工具类模块则大多被 Vite 预先合并成少数几个缓存文件。启动时不需要把整个项目的依赖图全部编译一遍自然就能做到秒级启动。但到了 build 链路Vite 实际上是交给底层的 Rollup 来完成打包大量代码分割、压缩、兼容处理仍然需要和 webpack 一样按模块图走一遍。如果项目本身巨大且没有做合理的缓存策略Vite 的 build 未必比 webpack 快多少。所以“换 Vite 之后一切都会变快”这个认知在大型存量项目里是不准确的。这也是为什么标题里的“webpack Vite”更贴近实践的真相开发阶段用 Vite生产构建继续沿用 webpack或者至少要保留 webpack 作为回归对照。等我们对 Vite 这条新链路有了足够的掌控力再逐步把生产构建也切过去风险才能被控制住。2. 拆开“快”字模块打包、依赖预缓存与 HMR 在两条路线里的本质差异2.1 模块视角webpack 是全量图Vite 是浏览器驱动的按需图如果只记一个结论我建议记这句话webpack 把浏览器当成“最终消费者”自己在服务端把所有模块打包成链路再交付Vite 把浏览器当成“运行时协作者”由浏览器主动请求模块Vite 只做中间翻译。webpack 的模块图构建过程大致是从入口文件开始通过 loader 转译文件内容解析 import/require逐层收集依赖最终形成一张完整的依赖图再按规则拆成 chunk写入到 dev server 的内存中。浏览器的每个请求拿到的都是已经打包好的资源。这套模型的好处是稳定、可控大量自定义 loader 和插件可以深度介入打包过程坏处就是冷启动慢项目越大启动时一次性开销越大。Vite 的模型则完全不同。开发时它不会把项目代码打包成 chunk而是把每个源文件映射成一个 ESM 模块地址浏览器请求哪个文件Vite 才对该文件进行即时转译。打个比方webpack 像一个在饭前就准备好整桌菜、按菜单分盘上桌的大厨Vite 则像按客人需求现场炒菜的开放式厨房客人报一个菜名厨师做一道做完了再问下一位。这种差异在项目规模变大的时候尤其明显。一个有着几十个路由、三四百个页面级组件的项目webpack 冷启动时的全量模块图构建时间会随着依赖树增长而线性甚至超线性上升Vite 的按需机制则让启动时间跟“当前页面实际请求了多少模块”有关而不是跟“整个项目有多少模块”有关。这也是我们从开发侧切入迁移的第一个原因。2.2 依赖预构建Vite 的缓存策略与 webpack 的持久化缓存策略很多人以为 Vite 快只是因为不打包其实还有一个容易被忽略的点依赖预构建。node_modules 里的第三方依赖尤其是那些以 CommonJS 格式发布的旧包直接交给浏览器 ESM 环境跑会有问题。Vite 的做法是在首次启动时扫描依赖入口用 esbuild 把这些依赖预打包成 ESM 格式并存放到 node_modules/.vite 目录下。esbuild 本身是用 Go 写的转译速度比传统 JS 链路的工具快一到两个数量级所以首次预构建虽然也要花点时间但比 webpack 的完整打包快得多。预构建结果会被缓存。只要你的依赖列表没有变化后续启动直接读缓存。这对开发场景特别友好第一次启动可能要等十几秒第二次基本就是秒开。我在迁移过程中还特意确认了 cacheDir 的配置位置因为某些 CI 环境会把 node_modules 当作临时目录每次重装后缓存被清掉Vite 就得重新预构建。后续我们在 CI 的缓存策略里单独保留了 .vite 目录才把重复启动的耗时压了下去。webpack 也有一套自己的 caching 机制比如持久化缓存filesystem cache。它会把模块转译结果、chunk 生成结果以序列化格式写入文件系统下次构建时优先复用。它和 Vite 的预构建缓存各有各的适用范围webpack 的缓存覆盖整个构建图包括业务源码和 loader 输出Vite 的缓存更多是面向第三方依赖。所以如果你在 webpack 里已经开好了持久化缓存生产构建的耗时并不一定比 Vite 差太多。判断工具优劣不能只看默认配置下的“第一感觉”。2.3 HMR 与生产构建两套链路要分开评估HMR热更新是另一个“快得感受明显”的环节。webpack 的 HMR 也是从模块图里找到变更模块再让浏览器执行更新逻辑但因为它要先完成对变更模块的依赖图更新计算项目大了之后热更新计算本身也会拖慢。Vite 的 HMR 则基于原生 ESM编辑一个文件后Vite 只向浏览器推送该模块的更新浏览器重新请求这个模块地址即可路径天然比 webpack 更短。我实测过同一个老页面的改动。原来 webpack 热更新平均 3 秒左右切到 Vite 之后基本在 300 到 600 毫秒。这个差距不是配置技巧可以抹平的而是模型层面的差异。所以如果团队最痛的是“改代码后等待时间太长”把开发链路切到 Vite 是性价比最高的方案。但生产构建不能照搬这个逻辑。Vite 的 build 默认由 Rollup 执行Rollup 在处理大型业务项目时也有自己的脾气比如它的默认分块策略、tree-shaking 效果、CSS 代码分割行为和 webpack 不一定一致。同样的项目webpack 可能打出几个很合理的公共包Rollup 可能打出多个小碎块或者在循环依赖、动态 import 拆包上表现不同。因此我建议把“生产构建”和“开发构建”当成两个独立问题来决策不要因为 dev server 跑得飞快就顺理成章地把生产构建也切过去。3. 双轨并跑的迁移路线Vite 开发热更 webpack 产物回归的共存方案3.1 迁移的第一步不是重写项目而是让两套构建进程并存我们当时的策略可以概括为开发上线用 Vite回归验证继续用 webpack。具体做法是先搭一个独立的 Vite dev server跑在固定端口并把接口请求、静态资源路径代理到已有的开发环境。业务代码先不做任何改动能跑通多少算多少。听起来很保守但这是最稳妥的切入方式。原因很简单存量项目里通常藏着大量隐性依赖比如 webpack 配置里定义了全局变量、别名、样式注入、自定义 loader这些东西不会自动适配 Vite。如果一上来就全量迁移报错数量会大到让人直接放弃。双轨并跑的意义在于团队成员可以先在 Vite 下享受快速热更同时随时切回 webpack 环境查看产物差异逐步把不兼容的地方一个个修掉。具体落地时我会先处理三类基础问题路径别名、环境变量注入、静态资源引用。路径别名改动影响范围最大因为业务代码里可能大量使用了一段固定路径前缀在 webpack 里通过 resolve.alias 指向某个目录在 Vite 里需要改成 vite-tsconfig-paths 或手动配置 resolve.alias。我们在迁移时先把 tsconfig 里的 paths 与 vite 的 alias 统一起来让两套配置指向同一份目录映射避免维护两套路径表。3.2 从“能跑”到“跑得稳”代码改造的优先级清单双轨跑通之后我们才开始按优先级改造业务代码。清单如下顺序是按“影响面大但收益也大”排的清除隐含的全局变量依赖。webpack 的 DefinePlugin 和 ProvidePlugin 在 Vite 里都有替代方案但不能默默照搬。区域配置里的全局变量可以通过 Vite 的 define 配置注入但那些依赖全局函数的代码最好改成显式的 import避免迁移后模块化边界不清。迁移样式预处理器的注入配置。老项目经常会在 scss/less 里注入全局变量、mixin 文件webpack loader 有额外参数Vite 里则通过 css.preprocessorOptions 配置。这一步要特别小心因为全局样式变量被注入后每个样式文件编译出来的结果可能不同差异排查很费时。处理第三方依赖的兼容层。部分老包依赖 Node 内建模块webpack 5 之前会自动注入 polyfillVite 默认不会。我们需要按需给这些包配置 alias 或添加 polyfill 脚本而不是全局引入一大坨兼容层。调整静态资源的访问方式。webpack 里 publicPath 和 file-loader/url-loader 的规则比较复杂Vite 则以 assetsInclude、base 配置替代。迁移时要把图片、字体等资源的相对路径和打包后的路径统一起来。验证动态 import 的路由分割。Vue 或 React 项目里大量使用动态 import 做路由懒加载Vite 对这类语法的处理基本兼容但分包数量可能不同。要在 build 阶段看产物差异避免出现某个页面包异常变大。当时我们按这个顺序改了两周Vite dev server 已经完全能支撑日常开发webpack 生产构建则一直保留作为发版基线。这段时间里日常开发效率明显提升但并没有立刻取消 webpack因为还要等一次完整回归来确认 Vite 不会引入兼容性问题。3.3 推荐的共存配置一份可以抄作业的骨架如果你也想双轨并跑可以直接参考我整理的最小配置骨架。项目保留 webpack.config.js 不动新增 vite.config.ts核心内容大致如下// vite.config.ts 最小共存配置示例 import { defineConfig } from vite; import vue from vitejs/plugin-vue; import path from path; export default defineConfig({ plugins: [vue()], resolve: { alias: { : path.resolve(__dirname, src), // 与老项目的 webpack alias 保持一致 }, }, server: { port: 5173, proxy: { /api: { target: process.env.API_TARGET || http://localhost:8080, changeOrigin: true, }, }, }, css: { preprocessorOptions: { scss: { additionalData: use /styles/variables.scss as *;, }, }, }, define: { // 注意define 里只能是可序列化的字符串或值 __APP_ENV__: JSON.stringify(process.env.APP_ENV || dev), }, });对应的 webpack.config.js 保持原样只在脚本 release 里增加一个回归构建命令。这样团队日常开发跑 Vite发布前跑 webpack build 做验证两套链路互不干扰。等到 Vite build 出来的产物在多次回归里都稳定了再考虑把发布脚本切到 Vite。4. 迁移之后才暴露的兼容性断层副作用文件、Node 内建与分包策略4.1 副作用模块一个容易让 tree-shaking 误伤的隐蔽问题双轨并跑期间我们遇到了几个典型问题第一个就跟模块副作用相关。webpack 在生产构建时会根据 package.json 里的 sideEffects 字段做 tree-shakingVite 底层交给 Rollup 时也有一套自己的判断。但问题在于某些第三方依赖的 sideEffects 字段声明并不准确明明会修改全局对象或注册自定义样式却被标记成了无副作用。这种包在 webpack 下可能因为模块图遍历方式不同而侥幸保留到了 Vite 就被错误地摇掉了。我当时排查一个老项目里的图表库现象是页面能打开但图表不渲染控制台只有一句“xxx is not a function”。最终定位到是某个工具包内部注册了全局扩展方法但因为 sideEffects 标记错误被 Rollup 在 build 时剪掉了。解决方式有两个一是在 package.json 里显式声明引入该文件二是用 Vite 的 optimizeDeps.include 强制预构建。如果你在迁移后碰到“某第三方功能在 dev 正常、build 消失”第一反应就去看 sideEffects。4.2 Node 内建模块Vite 不会替你默默做 polyfillwebpack 5 之前官方默认给浏览器环境注入 Node 核心模块的 polyfill所以很多老代码依赖 process、Buffer、path 这类模块也能跑。但 Vite 专门面向浏览器不会主动做这类兼容迁移后首当其冲的就是用到了 process.env 和 Buffer 的包。我们项目里就有两个历史工具函数用了 process.env.NODE_ENV 判断环境还有一个小型上传模块引了 Buffer。Vite dev 阶段因为浏览器环境可能自带部分兼容问题不明显build 阶段直接报错 module not found。处理办法分两步自己能控制的业务代码全部改成显式判断环境变量第三方依赖有这种问题就通过 resolve.alias 指向一个新的 polyfill 文件或者用社区维护的 polyfill 包按需注入。注意不要全量引入几十个 polyfill那只会白白增加产物体积。4.3 分包策略不一致Rollup 的默认行为未必符合业务预期第三个坑是 chunk 划分的差异。webpack 的 splitChunks 可以精细控制公共模块、node_modules 依赖、异步页面的分块策略Rollup 也有 manualChunks但默认行为更“轻”容易出现大量零碎小 chunk或者公共依赖被打进不同页面 chunk 导致重复加载。我当时用 Vite build 跑了一遍全量产物发现 vendor 包被打成了好几个小文件项目里几个大页面各自引了重复的工具方法整体体积比 webpack 版本多了将近 10%。后来在 vite.config.ts 里通过 build.rollupOptions.output.manualChunks 手动聚拢了高频依赖才把体积降下来。这一段没有通用秘诀得看自己项目里哪些依赖被多个页面复用。建议先跑一次分析报告再决定聚合规则。迁移后产物体积异常往往就是这一步没做而不是 Vite 本身膨胀。4.4 环境变量与浏览器兼容定向注入别一把梭最后说一下环境变量的注入差异。webpack 里 DefinePlugin 的写法是直接把整段文本替换成代码片段所以你可以把 JSON.stringify(process.env.X) 写进配置。Vite 的 define 配置同样做文本替换但更推荐使用 import.meta.env 的统一形式。迁移时我把老代码里的 process.env.XXX 都搜了一遍逐个改成 import.meta.env.XXX 或显式注入的常量。浏览器兼容层面Vite 默认构建目标是基于原生 ESM 的浏览器版本如果你的系统需要支持较旧浏览器记得设置 build.target并配合 autoprefixer 补全 CSS 前缀。我们因为只面向内网办公环境这个压力不大但如果你的产品面向外部客户这一步不能省略。5. 哪一种场景仍该留守 webpack面向团队与工程的选型判断表5.1 判断框架用“生态控制力”而不是“跑分”做决策聊到这里你可能会问既然双轨跑得通那是不是所有项目都该换 Vite我的答案是不一定。选型的关键不是看某个工具在 benchmark 里快多少而是看团队对构建链路的“控制力”。所谓控制力就是你遇到问题的时候能不能快速定位、修改、稳定复现解决方案。webpack 的优势在于插件生态悠久几乎所有历史遗留的怪问题都有人踩过Vite 的插件体系更年轻但已经覆盖了绝大多数日常需求。如果你团队的构建配置里塞了大量内部自定义 loader、自研插件或者依赖 webpack 严重的 loader 顺序和钩子机制那么强行迁到 Vite 可能要把这些自定义逻辑整个重写一遍成本远超收益。我见过一个反例一个维护了三四年的老系统webpack 配置足有一千多行里面有自研的国际化资源抽取插件、自定义文件指纹规则、特定 loader 链。团队花了三周试图迁移到 Vite最后因为自研插件无法平滑适配而回滚了。这类场景下最实际的优化不是换工具而是先清理老的 webpack 配置去掉无效 loader 和重复插件再开启持久化缓存把构建耗时降下来。工具切换是手段不是目的。5.2 一张粗糙但实用的选型表为了方便决策我把项目类型和推荐策略列成了一张表你可以直接拿自己的项目去对照项目画像推荐方案理由新项目没有历史包袱团队人数少直接用 Vite热更新体验好配置轻插件足以满足常见需求老项目webpack 配置复杂团队经验集中在 webpack保留 webpack先做配置瘦身和持久化缓存避免迁移风险收益也足够老项目代码量大但配置相对标准痛点集中在 cold start 和 HMR双轨并跑dev 用 Vitebuild 保留 webpack开发体验收益最大回归风险最小老项目且对生产构建体积、分包策略有严格指标谨慎迁移先对比产物Rollup 分包策略与 webpack 不同需要专门调优团队准备长期迭代愿意投入时间维护构建链路渐进迁移至 Vite长期收益更高开发与构建体验统一这张表不是标准答案但它能帮你快速分清自己手里的牌。我在团队的最终决定是开发环境全面切换 Vite生产构建暂时保留 webpack用一个半月的时间做回归对比再决定是否切换 build 链路。事实证明这个节奏让团队既能享受即时反馈又不会在关键发版前夜被构建问题拖住。最后想分享一个个人经验不要因为 Vite 的 dev server 快就默认它的 build 也快也不要因为 webpack 冷启动慢就否定它对复杂构建场景的掌控力。构建工具是工程土壤换土之前先看看根系扎得多深。与其把所有筹码押在某个“更时髦”的工具上不如让旧工具和新工具在项目里短暂共存用真实数据决定下一步。哪怕最终你选择完全不换工具这段“对比着用”的过程也会让你对自己项目的构建链路理解得更透彻。
