Vite打包的问题可以说是前端工程化里最让人头疼的一类事了尤其是从webpack迁移过来的团队经常会遇到“开发环境跑得好好的一打包就各种报错”的情况。这篇文章就是我做的vite打包问题记录主要围绕依赖预构建、资源路径、分包策略、老浏览器兼容和构建性能几个高频重灾区记录实际踩坑的过程和解决办法。不管你是刚开始用Vite还是已经上了生产环境遇到问题,应该都能在里面找到对应的排查思路。1. 先说清楚Vite打包为什么总和你预期不一样很多人在排查Vite打包问题时第一步就跑偏了原因在于没搞明白Vite开发环境和生产构建实际上是“两套引擎”在工作。1.1 开发环境与生产构建的“两套引擎”开发环境下Vite利用原生ESM按需加载配合esbuild做依赖预构建所以冷启动快、页面刷新快体验上比webpack好一大截。但生产构建时Vite默认换成了Rollup做打包esbuild只负责把部分代码做转换和压缩如果选用了esbuild压缩器。这两套引擎的差别会带来一个很隐蔽的问题开发环境验证过的代码到了打包阶段可能因为模块解析方式不同、tree-shaking行为不同、甚至CJS/ESM交互方式不同而报错或者行为异常。我之前经手的一个中后台项目就是典型的例子——开发环境一切都正常执行vite build时突然报某个库的导出不存在最后发现是那个库在开发环境走的是esbuild预构建后的ESM产物而生产构建直接处理原始CJS代码导出名被处理成了完全不同的一套。还有个容易忽略的点Vite默认“开箱即用”的配置只保证最常见的场景。一旦项目里出现老依赖、动态引用、多级子路径部署默认配置就会暴露问题。所以排查时要先建立两个认知起点开发环境正常不代表生产构建正常这是两套解析逻辑。默认配置能用但不是免费午餐碰到问题往往就是因为某个默认值和项目实际情况不匹配。1.2 三个高频翻车区域的共性原因从我记录的这些vite打包问题看翻车区域高度集中。我整理过一批生产项目的报错发现80%以上集中在这三类第一类是依赖预构建和模块格式问题。比如重复依赖、CJS模块无法转换、依赖缓存不更新等。这类问题在构建初始阶段出现表现形式是最直观的报错。第二类是资源路径问题。比如部署到子路径后白屏、图片404、CSS背景图失效。这类问题的特点是构建本身不报错但运行时表现诡异。第三类是构建产物问题。比如单chunk体积过大、动态导入命名不符合预期、老浏览器语法不兼容等。这类问题一般出现在构建完成后审查产物时才会发现。共性原因是同一个Vite把开发环境体验做到极致后很多模块规范和运行时细节被“隐藏”了。这有点像你平时开车走熟路从不看导航突然换一条新路就不知道看路牌了。Vite那些便捷性就是熟路换到生产构建这条新路上你必须重新理解路牌——也就是模块格式、路径解析、浏览器目标这些基础规则。2. 打包前必查依赖预构建里的三类坑依赖预构建是Vite的亮点也是vite打包问题最集中的源头之一。很多构建报错表面上看是代码问题深挖之后其实是依赖处理不当。2.1 重复依赖node_modules里藏着两套同名库重复依赖是前端项目里历史悠久的难题。npm的扁平化node_modules结构并不是每次都能生效不同包对同一条依赖声明的版本区间不一致就会导致安装出两个版本的库。第一次遇到这个情况时我排查了很久。当时构建后的产物里出现了一个模块被打包了两次的问题包体积明显膨胀而且运行时行为也不稳定——某个全局状态在一个版本里更新另一个版本读取时却是旧值。排查手段我推荐两种执行npm ls 包名检查依赖树里是否存在多个版本。我习惯带上--all参数能看到完整依赖关系。使用vite-plugin-inspect或者直接搜索产物看看同名模块是不是出现多次。解决方式要看具体情况如果是因为package.json直接声明了两个版本清理锁定版本如果是间接依赖闹的可以用resolve.dedupe字段强制Vite解析到同一路径。注意设置resolve.dedupe时要确认强制去重的版本确实兼容所有使用方否则只是把“报错”换成了“运行时崩溃”。2.2 CJS与ESM混用构建时报错的一大主力老项目迁移Vite时最常碰到的就是CJS模块转ESM失败的问题。Vite预构建阶段会把依赖统一转换成ESM但有些老库的写法非常“Native CJS”比如内部用module.exports动态生成导出、使用__dirname拼路径或者用require做条件加载。esbuild在预构建时多数能处理但到了Rollup生产打包阶段面对插件的CJS输出处理方式更严格稍微不合规就是构建失败。一个经典报错是构建时提示某个依赖的默认导出找不到指向可能是export default的编译结果异常或者是interop问题。这类问题我建议按顺序排查先用optimizeDeps.include让Vite在预构建阶段强制转译该依赖看报错是否消失。如果还是报错说明库本身CJS写法太“硬”esbuild处理不了只能想办法替换依赖。替换依赖有两条路找一个纯ESM的替代库或者用别名把依赖指向某个兼容好的fork版本。之前有个图像压缩库折腾了半天最终就是通过别名替换成同功能的纯ESM实现解决的。如果问题不是不能转换而是转换后运行时行为不对还可以在构建阶段引入一个CJS插件做额外处理。但我的经验是能用替换解决的就不要硬修维护一个没人维护的老库兼容层成本会一直累积。2.3 依赖更新失效缓存比你的预期更顽固Vite预构建产物的默认缓存路径在node_modules/.vite它的存在让二次冷启动快很多但也带来了存量项目的烦恼——你改了package.json里某个依赖的版本号构建产物却还是旧版本。原因很直接Vite判断缓存是否失效依赖的是锁文件内容、部分配置和依赖包的时间戳。锁文件没变、时间戳没更新就会继续用旧缓存。遇到这类问题最粗暴也最有效的办法是手动删除缓存目录同时加上--force参数重新构建rm -rf node_modules/.vite npx vite build --force如果是CI环境我更推荐在构建命令前把.vite目录排除在缓存之外或者每次构建执行前都用vite optimizeDeps重新计算依赖。注意CI的缓存策略要设计好依赖安装缓存可以留预构建缓存建议每次都重算否则某次依赖更新后构建结果会“看起来成功实际上用了旧依赖”这类问题比直接报错更难排查。3. 部署后白屏资源路径问题的完整排查思路资源路径问题有个特征本地构建预览一切正常上传到服务器、套一层子路径访问就白屏。原因是构建产物里的资源引用路径是根路径/而你部署的站点实际是在https://域名/子目录/下访问于是/assets/index.js这个地址自然找不到文件。3.1 base配置没对换个子路径就白屏Vite中控制资源引用路径的核心配置就是base。默认值是/意味着所有JS、CSS、图片资源都写成绝对路径根路径形式。如果你的部署环境要求子路径需要把base改成相对路径或者完整子路径// vite.config.ts export default defineConfig({ base: /admin/, // 部署在 https://域名/admin/ // base: ./, // 也可以用相对路径但需要注意后续路由问题 })我个人更推荐显式设置为实际的子路径前缀。设置为./虽然是常用方案但会带来另一个问题动态加载的chunk和部分异步资源的相对路径解析依赖当前页面URL如果在某个深层次路由下刷新相对路径可能解析到错误层级导致白屏。设置base之后要记得检查路由的history模式。用vue-router或react-router时createWebHistory的base参数要跟Vite的base保持一致否则刷新页面会404。3.2 public与assets的分工经常被搞错另一个路径问题的来源是搞不清楚public目录和assets目录的区别。public目录下的文件会原样复制到构建输出的根目录不做内容哈希引用时写绝对路径例如/favicon.ico。src/assets目录下的文件经过编译处理会生成带哈希的文件名并且可以通过导入语句获得解析后的URL。常见的错误用法有两个方向一种是把需要“构建处理”的图片放到了public目录结果上线后文件名不带哈希升级版本时浏览器缓存不刷新用户看到旧图。另一种是试图在代码里用/src/assets/xxx.png这种字符串路径加载资源而不是通过import或new URL。结果构建时Rollup根本不会处理这种裸字符串运行时404。正确做法是import logoUrl from /assets/logo.png // 通过导入获取处理后的URL const imgUrl new URL(../assets/img.png, import.meta.url).href // 动态场景用这个3.3 动态引用和字符串拼接的路径陷阱我可以说是被“字符串拼接路径”坑过很多次了。遇到那种需要根据变量拼接资源路径的场景比如const url /assets/ name .png构建工具永远无法提前知道最终URL是什么所以不会帮你重写路径、加上base前缀。一旦部署到子路径就会404。这类的正确处理方式是使用new URL(url, import.meta.url)让Vite把它识别成一个“资源引用”从而在构建时做处理const imgUrl new URL(../assets/${name}.png, import.meta.url).href还有一个路径相关的问题很容易被忽视CSS文件里的url()相对路径。如果CSS里引用了../images/bg.png构建后这个相对关系在产物文件里可能发生改变导致背景图404。这类问题排查时要优先检查base配置和CSS文件所在的目录结构关系。4. 分包策略把“巨型chunk”拆成可维护的多文件构建后出现单个超大的JS文件是Vite构建非常典型的反馈之一。默认情况下由于应用代码和所有node_modules依赖都在同一个入口图里Rollup会把它们打包进一个chunk。文件一大问题就来了加载速度慢、缓存失效严重、并行下载的优势全丢了。4.1 为什么要手动分包以及默认打包的痛点Vite构建后出现一根超长的index-xxxx.js几百KB甚至上MBESLint的构建警告也提示超过了建议值。对首屏来说一个巨大JS文件意味着下载时间长、解析时间长而且哪怕只改了一行业务代码整个文件缓存就失效了。手动分包的核心思路很朴素把变化频率低、体积大的依赖单独拆出来成一个或多个chunk让浏览器长期使用缓存。同时减少大chunk的整体体积让业务代码更新时不只是重新下载全量文件。在Rollup配置里最常见的手段是设置output.manualChunks函数build: { rollupOptions: { output: { manualChunks(id) { if (id.includes(node_modules)) { if (id.includes(react) || id.includes(react-dom)) return react-vendor if (id.includes(lodash)) return lodash-vendor if (id.includes(echarts)) return echarts-vendor return vendor } } } } }4.2 一个可用的manualChunks配置与取舍上面的示例是基础版实际项目里要注意两点第一别把所有node_modules都丢进vendor一个文件。理想的是把体积大、更新少的库独立拆出来UI框架一包、图表库一包、工具库一包。但也不是拆得越细越好拆太细会造成HTTP请求数暴涨HTTP/1.1下连接数不够用HTTP/2下虽然好一些但文件碎片太多也会增加开销。第二手动分包时要注意业务模块和依赖模块之间的边界。如果某个业务模块A被拆出来而另一些业务入口还需要模块A的代码就会出现重复。我之前踩过的一个坑是把一个公共业务组件拆进了一个独立chunk结果有两个异步路由都引了它构建产物里出现了两个模块实例运行时状态不一致。比较稳妥的做法是先不急着写死规则而是利用manualChunks函数遍历模块路径对node_modules下体积足够大的库单独分包再让剩余部分统一进入vendor。构建完成后用rollup-plugin-visualizer看产物结构再决定是否进一步拆分。提示如果项目使用了异步路由一定要检查分包后每个异步chunk体积是否合理。你可能会发现一个懒加载页面打包后高达几百KB这时通常是因为该页面直接import了图表库或巨型工具库需要做按需引入。4.3 动态导入命名与依赖预构建的配合Vite构建动态导入webpack语境里的动态importVite里对应Rollup的代码分割时默认的chunk名称可能是0-xxx.js这种无意义名字。许多人希望看到类似Login-xxxx.js这样直观的命名。在vite.config.ts里这样配置build: { rollupOptions: { output: { chunkFileNames: assets/[name]-[hash].js, entryFileNames: assets/[name]-[hash].js, } } }关键是[name]从哪里来。Rollup会使用代码注释里的魔法注释或者手动分包时返回的字符串作为chunk名const Login () import(/* webpackChunkName: Login */ /views/Login.vue)注意这个魔法注释并不是webpack特有的。Rollup同样识别webpackChunkName所以从webpack迁移过来的项目可以直接沿用。不过格式是/* webpackChunkName: Login */如果你的项目之前没有写构建后就是一堆编号文件排查问题非常难受。依赖预构建这里也有一层联系如果某个依赖在预构建阶段已经被转换成ESM那分包时Rollup是按转换后的模块ID来识别的。如果你改了optimizeDeps的配置可能会导致分包规则失效因为依赖ID路径变了。所以调整分包配置时最好同时清理一下.vite缓存否则你看到的产物结构可能还是旧逻辑下的产物。5. 兼容老浏览器从语法降级到垫片补齐Vite默认构建目标设定为“现代浏览器支持”所以产物里会直接保留ES2015语法。如果你的用户群体里有人用旧版浏览器比如还在用较老的chrome、旧版safari、部分国产浏览器内核就会发现“开发环境好好构建后有的电脑能打开有的直接白屏”而且控制台报错往往是一个看不懂的语法错误。5.1 为什么开发环境跑得欢老浏览器直接白屏因为默认build.target是基于浏览器原生支持ESM和动态import来设定的。Vite相信能用ESM的浏览器肯定也支持较新的语法所以构建时不会刻意把语法降级到很老的地板。可现实是不少浏览器虽然支持ESM基础能力但对一些比较新的语法特性支持并不完整。如果你的项目有兼容老浏览器需求第一步要设置build.targetbuild: { target: es2015 }但这里有一个重要限制esbuild做的语法降级只负责语法层面不负责运行时API垫片。也就是说语法可以转成ES2015但像Promise.allSettled、Array.prototype.includes、Object.entries这些API浏览器不支持就是不支持必须额外引入polyfill。5.2 用legacy插件做双轨构建解决完整兼容的方案是使用vitejs/plugin-legacy插件。它做的事情比单纯设置target更彻底构建时会生成两套产物一套给现代浏览器一套给旧浏览器并在HTML里通过nomodule和modulescript标签把它们区分开来。import legacy from vitejs/plugin-legacy export default defineConfig({ plugins: [ legacy({ targets: [ie 11, chrome 52], additionalLegacyPolyfills: [regenerator-runtime/runtime], }) ] })启用legacy插件后有一个明显副作用构建时间变长因为要同时生成两套代码而且旧代码需要额外做语法降级和polyfill注入。如果项目确实只需要支持“近年内的部分老浏览器”可以把targets范围适当收窄能显著降低构建成本。我之前遇到的一个案例是某系统需要兼容特定政企环境的旧内核浏览器。当时用legacy插件成功解决但代价是构建产物体积增加了约30%。如果产品本身对首屏体积有极端要求就需要在“兼容范围”和“体积成本”之间做取舍。5.3 垫片加载和数据兜底的排查顺序用了legacy插件后还有一种情况不容忽视HTML里加载polyfill的scripts是动态插入的如果某些老浏览器对ESM语法识别有问题可能会发生“页面倒是加载了脚本逻辑全没执行”的怪现象。排查顺序我记录的经验是按下面这个顺序来先用控制台看具体报错。如果报错是“Unexpected token”之类多半是语法降级没覆盖到排查targets配置。再检查network面板看看是否多了一个legacy脚本请求。如果这个脚本404说明生成产物缺少legacy文件需要确认插件是否生效、缓存是否太陈旧。最后检查运行时API问题。页面可以打开但功能按钮点击无反应控制台报xxx is not a function这是polyfill没补齐要到additionalLegacyPolyfills里补充对应的库。还有一个小技巧浏览器宽容度问题可以用vite build --mode legacy这种模式区分构建产线。比如现代版和兼容版分别构建方便不同渠道部署但注意CI脚本要写清楚。6. 构建性能调优几分钟的构建时间可以压到几十秒Vite的开发体验快不代表生产构建一定能快到令人满意。尤其是项目依赖多、页面多、类型复杂时vite build耗时可能接近甚至超过webpack时代的水平。这一章节我给出一套实用的构建性能调试方法。6.1 先搞清楚瓶颈在哪里构建时间主要消耗在转换、打包、压缩三个阶段。我常用的方法是先跑一次vite build --debug或者用DEBUGvite:build*环境变量DEBUGvite:build* npm run build日志会把每个插件、每个阶段的耗时打出来比瞎猜靠谱得多。比如你会发现vite:resolve阶段耗时异常高那说明解析模块的路径判断有大量无效工作如果transform和renderChunk耗时长可能是压缩器和代码规模的问题。速度慢还有一个隐藏因素项目引用了大量不需要的模块。比如图标库全量引入、工具库全量引入。虽然tree-shaking能清除一部分死代码但模块图依然庞大解析时间跑不掉。这种只能靠按需引入来解决。常见的时间消耗统计我碰过的大致是这样耗时阶段常见原因对应解决方向解析模块耗时高依赖过多、路径别名配置差按需引入、简化别名匹配transform耗时高TS/JSX转换、插件处理大量节点检查插件顺序、减少全量transform打包耗时高chunk图复杂、代码分割过细调整分包策略、降低chunk数量压缩耗时高terser单线程压缩大文件更换esbuild压缩器或配置并行6.2 压缩器、sourcemap与构建参数的取舍Rollup的默认压缩器是terser它的压缩效果细致产物体积小但速度实在不快。Vite官方也推荐可以在生产环境换成esbuild压缩器速度能提升好几倍代价是压缩效果略差、个别高级语法优化没有terser精细。build: { minify: esbuild, target: es2015 }实测下来在某个中后台项目上terser构建总时间约140秒切换esbuild后降到约40秒产物体积增大2%左右。考虑到绝大多数场景体积增量可以接受整体收益非常明显。如果项目对体积和极致压缩高度敏感再考虑保留terser。sourcemap对构建时间的影响也很大。生产构建如果需要生成sourcemap用于排查线上问题这个阶段会额外增加不少耗时体积也会明显增大。我的建议是开发阶段保留sourcemap生产阶段如果技术团队能通过日志定位就把sourcemap关闭。如果真需要线上排错可以考虑只在特定环境变量下才开启比如build: { sourcemap: process.env.ENABLE_SOURCEMAP true }6.3 按需加载与依赖分析工具性能调优到后期还是要回归到依赖分析和按需加载。工具方面推荐两个rollup-plugin-visualizer看产物构成定位哪些依赖塞满了大体积chunk。vite-plugin-inspect看模块处理细节定位某个模块到底经历了哪些插件转换。在依赖层面优先检查几类重量级库echarts全量引入 vs 按需注册图表。lodash全量引入 vslodash-es按需导入。dayjs插件、语言包全量加载 vs 按需精简。图标库全量注册 vs 按需注册。这些改完后构建产物和构建时间常有比较明显的提升。把依赖分析和按需引入当成常态而不是等出问题再去处理长期维护体验会好很多。7. 高频报错速查表与我沉淀的排查流程先放一张速查表把我的vite打包问题记录里最常用到的排查对应关系列出来。这张表针对的是高频常规场景更偏门的情况还需要结合堆栈逐层看。7.1 高频报错速查表报错现象大概率原因解决思路构建报某依赖export不存在CJS/ESM混用、依赖版本冲突optimizeDeps.include或替换纯ESM库部署子路径后白屏base配置不正确将base配置为实际子路径前缀图片404或不带哈希资源放到了public目录改用import引入或new URL方式单chunk超过500/600KB依赖过大、分包颗粒度粗手动分包大依赖调整chunk策略老浏览器白屏语法未降级或polyfill缺失配置legacy插件和targets构建时间过长压缩器慢、依赖未按需引入切换esbuild压缩器、按需加载缓存导致产物旧.vite目录缓存未清理删除缓存加--force构建7.2 通用排查步骤遇到不熟悉的构建报错我建议按这套流程走一遍比零散查找效率高第一步跑一次干净构建。清空node_modules/.vite和dist目录重新执行npx vite build --force。排除缓存干扰。第二步看完整终端输出。不要只看报错第一行向上翻能看到是哪一步解析失败的大多时候都会显示具体的文件名或依赖名。第三步最小化复现。把业务代码排除只保留报错的依赖和最小入口如果你的项目在最小复现下不再报错说明问题业务代码继续二分法缩小范围。第四步用vite.config.ts里逐个段落注释的方法定位配置冲突。配置项目越多越要隔离试验。第五步去对应依赖的GitHub issue区搜相同报错。很多报错都有已知的解决方案比你自己反复调试更快。7.3 我对Vite打包这件事的真实体会记录这一路vite打包问题处理我的最大感受是大多数问题并不是Vite本身不够好而是开发者包括我在迁移时习惯性带着webpack时代的惯性思维把开发环境当成了完整验证环境。Vite的开发体验太顺滑了导致很多人误以为“开发能跑生产没问题”直到构建阶段才被现实教育。我更推荐的做法是把Vite的构建检查前移到研发流程中。在功能分支合入前就执行一遍vite build作为基本门槛在CI里面可以加一个产物体积对比的插件至少知道某个改动是否让chunk体积暴涨。这样很多打包问题能在开发阶段暴露而不是上线当天才发现。另外最后再分享一个小技巧把一份“最适合自己项目的vite.config.ts”沉淀成项目模板把分包策略、legacy兼容、路径配置都写成带注释的默认值。我接手新项目时第一件事就是把这套配置复制过去再根据项目特点微调。这样踩过的坑就不会再踩一遍后续同学也可以把新的问题记录追加到注释里团队知识能持续传承下来。
