做前端这几年前后端工程化的重心一直在变。早些年项目里没个webpack.config.js都不敢说自己是正经前端工程。这几年vite起来之后越来越多的团队开始往这边迁。我接手过一个老后台项目从webpack切到vite之后冷启动从十几秒变成不到两秒开发体验确实是质的飞跃。但迁移过程中踩了不少文件处理相关的坑比如同样的图片路径配置webpack里能跑vite里就是404同样的懒加载写法一个分包策略完全不一样。这篇文章就把webpack和vite在文件处理上最核心的差异掰开揉碎讲清楚包括模块解析、静态资源、CSS、代码分割、缓存这块的处理逻辑最后给一份同一需求的对照配置。不管是准备迁移的还是想理解这两个工具底层思路的都能从这里找到解答。1. 打包理念的分水岭bundle工厂 vs 原生ESM1.1 webpack的模块图宇宙一切皆模块一切皆打包webpack的核心思想是把整个项目里所有的资源——JS、CSS、图片、字体、模板全部看成模块然后用一套统一的依赖分析机制把它们串成一张巨大的模块图Module Graph。入口文件是根源通过import/require语句不断往外扩展分支每个分支都会被打上依赖标签。分析完整个依赖关系之后webpack根据一个确定的入口把这些模块按照运行时依赖的顺序合并输出成浏览器能直接执行的bundle文件。这套设计的出发点很好理解webpack出现的年代浏览器对原生ESM的支持还很差也没有统一的大模块加载规范各种CommonJS、AMD、UMD混着用。webpack在中间加了个运行时runtime抽象层用一小段启动代码在浏览器里模拟出模块导入导出的环境最终让开发者不用关心底层模块格式的乱局。webpack仓库里有一句著名的话webpack is a static module bundler for modern JavaScript applications打包前它会对模块状态做静态分析编译成静态资源。也就是说webpack做的是打包时静态编译它希望你所有的文件都在启动前就被显式地搜集起来。这个设计决定了webpack文件处理的一个关键特性任何资源想被引用都必须通过module系统。哪怕是一个图片、一个字体文件你必须在JS里import img from ./logo.png或者在CSS里写url(./bg.png)webpack才能通过loader把它识别成模块、纳入依赖图。否则它在build出来的资源里是找不到这个文件的直接问file not found。所以很多新手用webpack的时候会觉得我明明把图片放在public目录了为什么编译后找不到其实是把webpack的理解方式搞反了webpack里没有非模块资源这个概念只有我有没有通过构建语法去引用它的区别。1.2 vite的双轨制开发环境交给浏览器生产环境交给Rollupvite的核心突破在于它想清楚了开发和构建其实是两个完全不同的场景不该用同一套机制处理。开发环境下vite直接利用浏览器原生ESM能力把打包这一步完全省略掉。它做起了一个超级轻量的dev server你在源码里写import { createApp } from vue浏览器真的就按这个路径去发HTTP请求了——vite启动后你的源码几乎是原封不动地被浏览器拉取只有当浏览器请求到某个文件时vite才去编译那个文件本身。注意这里有个很重要的细分webpack启动时要把整个项目的模块图全部分析完、打包成bundle然后才对浏览器提供服t同时意味着整个项目的构建时间就是启动时间。vite则完全不同它只启动一个秒开的服务器真正耗时的是按需编译也就是浏览器问一个它转换一个。你开发时只改一个小文件浏览器也只重新请求这一个文件不会去重新分析全项目。到了生产环境vite才真正做起打包这件事但用的不再是esbuildesbuild因为代码分割等方面不成熟生产环境打包有隐患而是集成了已经非常稳定的Rollup。这形成了一个双轨制开发环境只管快生产环境只管稳。这也是为什么很多人在网上看到vite比webpack快10倍的结论其实往往是针对于开发环境冷启动和HMR。生产环境构建时长上vite相较于webpack的提升并没有那么夸张大概也在1.5到2倍的范围浮动但这已经是很好的改善了。1.3 bundle vs no-bundle对文件处理的影响到底有多大理解了这两种理念你会发现webpack和vite处理文件的方式本质上是被架构逼出来的而不是间隔上的选择。依赖图的构建时机webpack在启动时就必须建立完整模块图所以它对所有文件都要做静态分析、loader变换、依赖解析文件数量一上去构建时间就指数上升。vite则把依赖图的构建推迟到浏览器实际请求这一刻所以它甚至不需要提前知道整个项目的模块结构。这个差异让vite在大型项目里的冷启动速度碾压webpack。文件编译的粒度webpack编译的最小产物单元是模块但最终提交给浏览器的是打包后的大块bundlevite开发环境下一个文件就是一个可请求的URL浏览器拿到的是真正按需加载的ESM没有多余的启动器代码、没有闭包包裹。模块解析的策略webpack有一个非常庞大的模块解析逻辑支持alias、extensions、mainFields、resolve.modules等一堆配置vite也支持alias但底层走的是Node的ESM解析规则再加上自己的resolve Plugin很多以前webpack里需要配置的东西vite里直接简化了。2. 模块解析与文件转换链路的差异2.1 webpack的loader流水线所有文件都要过安检webpack世界的核心入口是module.rules。你每给一种文件类型安排一个loader就相当于给这类文件配了一条安检通道。loader是函数式的从右往左执行也就是说use: [style-loader, css-loader, sass-loader]的执行顺序是sass-loader先跑然后是css-loader最后是style-loader。这个顺序不能乱因为每个loader的输出都是下一条loader的输入sass-loader把SCSS编译成普通CSScss-loader处理掉CSS里的import和url()引用把CSS变成一个JS模块style-loader则是把这个JS模块运行时注入到style标签里。这里要注意一个常见的坑所有loader都是通过转换文件内容来让webpack认识并处理它。比如babel-loader把ES6转换成ES5ts-loader把TypeScript编译成JavaScriptvue-loader把.vue单文件组件拆解成JS、HTML、CSS三个部分再分发到对应loader。如果没有loaderwebpack不知道如何处理这些文件会直接抛Module parse failed错误。你还会发现引入一个新的文件类型几乎意味着就要给webpack配置一条新的loader链。想一想CSS隔离方案webpack需要借助css-loader的modules选项处理图片和字体要配置asset模块或者老的url-loader/file-loader处理SVG可能要装svg-inline-loader压缩图片要装image-webpack-loader……每多一个文件类型就多一层配置决策。2.2 vite的插件体系武器库更统一处理路径更直接vite文件处理的核心是它的插件机制。开发环境下vite的dev server本质上是一个中间件体系插件可以通过transform钩子拦截模块的编译过程把请求到的模块内容按需转换后再发给浏览器。生产环境下同一个插件可以同时作用于Rollup打包阶段实现一次编写、双向生效。例如你用vitejs/plugin-vue处理.vue单文件组件它会像vue-loader一样去解析模板、样式和脚本但解析出来的产物是真正的ESM代码而不是webpack里那种触发各种loader的中间格式。处理CSS、SCSS、Less、图片、JSONvite大部分内置了基础能力不需要额外配置loader。你要做一个aliasvite里只需要在resolve.alias里配置底层走的是Node的import.meta.resolve逻辑简洁很多。另外一个专业细节vite开发环境支持对第三方依赖做预构建dependency pre-bundling通过esbuild把node_modules里的CommonJS/UMD包转换成ESM并合并所有内部依赖到一个文件里。这样做的根本原因是很多npm包是CommonJS格式浏览器原生ESM无法直接import同时如果不对它们做打包浏览器请求很多细碎的小模块HTTP请求数会爆炸。预构建完成后vite会把这些结果缓存在node_modules/.vite目录下。但是这也带来了一个开发时挺常见的问题如果你改了某些依赖的版本或者手动改了node_modules里的内容vite不会自动重新预构建常常需要手动删掉node_modules/.vite缓存重启。2.3 文件后缀解析和模块导出两者对这些微妙规则的处理webpack的resolve.extensions默认是[.js, .json, .wasm]所以你在代码里写import ./foowebpack会依次找foo.js、foo.json、foo.wasm。实际项目中我们通常要扩展.vue、.ts等后缀否则import文件不带后缀会找不到。vite则默认支持.js、.ts、.jsx、.tsx、.json、.vue等主流后缀有时你会发现webpack迁移项目到vite后原来代码里写import ./style.scss不带.scss后缀在vite里反而找不到了因为vite默认不解析.scss后缀必须带完整后缀。这不是vite的毛病而是ESM的规则更严格浏览器里你必须给出精确的相对路径vite只是尊重了这个规则而已。模块导出方面webpack出于历史原因既支持ESM也支持CommonJS甚至你可以在同一个模块里混用vite在开发环境只认可ESM语法遇到CommonJS的包就交给预构建去转换它对混用的情况限制更严格。这种严格但清晰的风格也反映了vite的设计哲学导向更好的现代模块规范而不是向后兼容所有历史垃圾代码。3. 静态资源与CSS处理最容易翻车的地方3.1 图片、字体等静态资源asset modules vs import URL机制这是文件处理里最容易出坑的一块。webpack从5开始官方推荐用asset modules统一处理所有静态资源替代老旧的file-loader、url-loader、raw-loader。{ test: /\.(png|jpe?g|gif|webp|svg)(\?.*)?$/, type: asset, parser: { dataUrlCondition: { maxSize: 8 * 1024 // 小于8KB的图片转base64内联 } } }type: asset的行为很灵活超过8KB输出成独立文件低于8KB直接base64内联到JS里。这也解释了为什么你webpack打包完代码里明明引用了图片产物体积却小得可怜——全部被内联成base64了。如果你想要所有图片都输出成独立文件用type: asset/resource如果你想要所有图片都内联用type: asset/inline。老项目里如果还留着file-loader、url-loader的配置迁移时可以直接简化掉。vite里的图片处理逻辑更简单直接。你在src目录下放一张图片然后像import模块一样去引用它import logo from /assets/logo.pngvite在编译时会把这张图片按资源处理如果小于4KB转成base64内联如果大于4KB输出到构建产物目录默认assets并返回对应的URL。这个4KB阈值可以通过build.assetsInlineLimit配置比如你想让小于10KB的都内联可以设置成1024 * 10。跟webpack通过type区分方式不太一样vite直接根据资源大小自动决定内联还是外链这避免了webpack里同一张图片在开发环境和生产环境里处理方式不一致导致的怪异bug。另一个重要区别是public目录。vite里有个约定是public目录下的文件不会被打包处理而是原样复制到构建根目录dist的根下。你在代码里引用public目录下的资源需要写绝对路径/foo.png或者直接写img src/foo.png。webpack没有这个public目录不受模块系统控制的约定它的publicPath是控制输出资源的引用前缀很容易让新人混淆。这里必须分享一个我踩过的坑vite项目里如果在CSS里用相对路径引用了一张图片比如background: url(../assets/bg.png)在开发环境没问题但生产构建后Rollup会尝试把所有URL资源解析并处理。如果路径写得不规范比如带别名但CSS预处理阶段没有正确解析alias构建后图片路径就会变成404。webpack里常见的解决方案是resolve.alias配合url-loaderCSS里的相对路径问题不大但vite如果你不在CSS里写成相对路径就别指望后期自动改建议在vite里直接用/src/assets/bg.png这样的绝对路径前缀或者干脆用import bg from /assets/bg.png引入再内联到样式中能避开一堆路径问题。3.2 CSS处理从注入到提取再到CSS Moduleswebpack处理CSS开发和生产完全靠配置区分。开发环境css-loaderstyle-loader的组合会把CSS通过style标签注入到页面生产环境你要把CSS替换成独立文件于是换成MiniCssExtractPlugin.loader把所有的CSS收集起来提取成最小化的CSS文件。如果你要用CSS Modules得在css-loader的options里改modules: true。vite处理CSS则优雅一些开发环境自动注入它会把CSS编译成ESM浏览器请求时动态执行本质上也是将CSS代码注入到style标签里生产环境自动提取Rollup会把所有相关CSS合并输出到一个文件里当然你也可以通过配置拆成多文件。vite内置了对CSS Modules的支持文件名以.module.css结尾就会按CSS Modules处理。同时vite还内置了PostCSS——你只要在项目根目录放一个postcss.config.js文件vite会自动load它。对于SCSS、Less这些预处理器vite也不要求你装loader它内部会动态调用preprocess插件你只要在preprocessorOptions里传参数配置即可css: { preprocessorOptions: { scss: { additionalData: import ./src/styles/variables.scss; } } }这个additionalData的功能是给每一个SCSS文件自动注入一些公共变量类似webpack里sass-loader的additionalData配置。使用时要小心如果你在全局注入里又import了一个带样式的文件会产生大量重复代码所以通常只放variables和mixins。CSS在不同框架里的表现差异也比较明显webpack处理Vue的scoped样式时vue-loader会为每个组件的style块生成一个特殊的data属性选择器vite里则是vue/compiler-sfc来添加data-v-xxx属性。两者实现的CSS隔离最终效果差不多但过程完全不同。4. 代码分割、懒加载与缓存策略4.1 代码分割webpack的SplitChunks vs vite的manualChunks代码分割是优化首屏体积、提高缓存复用的核心手段。webpack的代码分割主要靠optimization.splitChunks它有一定智能分包策略默认会将node_modules里的第三方库单独打包成一个chunk并且对多个入口共享的模块做提取。你可以用cacheGroups精细化控制比如把vue全家桶划进一个chunk、把UI组件库划进另一个chunkoptimization: { splitChunks: { cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: vendors, chunks: all }, ui: { test: /[\\/]node_modules[\\/](ant-design-vue|element-plus)[\\/]/, name: ui, chunks: all } } } }vite则是基于Rollup做代码分割默认情况下动态import的模块会被单独分割成一个chunk这是原生ESM动态导入机制带来的红利。如果你想把第三方依赖也拆出来用build.rollupOptions.output.manualChunks配置。这个配置可以传一个对象也可以是一个函数。build: { rollupOptions: { output: { manualChunks: { vue-vendor: [vue, vue-router], ui-vendor: [ant-design-vue] } } } }但manualChunks有个容易踩坑的点手动分包时如果模块之间共享了相同的依赖拆分后可能造成重复模块、循环引用之类的问题特别是你在对象写法里漏掉了一些依赖。所以我的建议是能不用manualChunks就别手动拆让Rollup自动按动态导入去分包除非你明确知道自己在干什么。还有一个小区别是区块命名webpack里你可以自由控制chunk文件名vite里生产构建出来的文件默认带hash命名规则如index-abc12345.js如果你想自定义文件名要在rollupOptions里改entryFileNames、chunkFileNames等配置。4.2 Hash策略与长效缓存webpack的三重hash vs vite的contenthash浏览器缓存策略里文件名带hash是核心。webpack的hash种类非常多经常搞晕新人[hash]每次构建都会变所有文件都一样基本不建议使用[chunkhash]根据chunk内容生成同一个chunk里的文件hash相同不同chunk不同[contenthash]每个文件单独根据内容生成只有当文件内容变化时hash才变这是长效缓存的最优选。webpack配置时你常常需要给js用chunkhash、给css用contenthash还要配合runtimeChunk: single把webpack的runtime单独拆出来否则改了业务代码整个vendors chunk的hash也会跟着变缓存就等于白搭了。vite的处理则简洁很多。开发环境下文件不受hash控制生产环境下Rollup默认使用[hash]作为文件名这个hash是每个文件根据内容生成的其实就是contenthash。换句话说vite把webpack里手动选hash类型的这个决策简化了默认就是最适合长效缓存的方案。但如果你希望文件名不带hash比如为了某些静态部署场景可以配置build.rollupOptions.output.entryFileNames: assets/[name].js。这个简化对整个缓存体系影响很大webpack里改一行代码导致第三方库缓存失效的问题是常态vite从设计层面就规避了。你不需要关心runtime chunk之间的依赖关系Rollup在生成产物的时候会自动拆分、自动命名缓存策略天然合理。4.3 HMR与文件监听更新粒度的差异HMR的差异也是两者文件处理的巨大分水岭。webpack的HMR需要重新构建模块图哪怕只改了一个文件它也要把相关chunk重新生成虽然webpack5改进了用持久化缓存cache.buildDependencies可以缓存部分模块的编译结果但依然需要重新跑模块图分析再通过websocket通知浏览器替换模块。vite的HMR则是建立在原生ESM的模块树之上。浏览器的import语句天然构成模块依赖关系vite只需要在dev server上动态维护这些依赖的精确更新边界。你改了一个Vue文件vite只需要通知浏览器这个文件变了浏览器自己去重新请求这个模块并执行hot update逻辑。由于没有打包负担它几乎能做到毫秒级的响应。文件监听这块vite用的是chokidar监听文件系统事件webpack也一样但两者在处理变动的起点和终点完全不同懂HMR的原理就更好理解为什么vite手感好这么多。5. 实操配置对照同一份需求两种配置写法5.1 场景设定Vue3 TypeScript SCSS 图片资源为了直观对比我拿一个最常见的场景来测一个Vue3项目用TypeScript写逻辑样式用SCSS页面里要加载图片和字体还要做路由懒加载。webpack这边核心配置文件大概长这样// webpack.config.js const path require(path); const { VueLoaderPlugin } require(vue-loader); const MiniCssExtractPlugin require(mini-css-extract-plugin); const HtmlWebpackPlugin require(html-webpack-plugin); module.exports { entry: ./src/main.ts, output: { path: path.resolve(__dirname, dist), filename: js/[name].[contenthash:8].js, chunkFilename: js/[name].[contenthash:8].js, publicPath: / }, resolve: { extensions: [.ts, .tsx, .vue, .js, .json], alias: { : path.resolve(__dirname, src) } }, module: { rules: [ { test: /\.vue$/, loader: vue-loader }, { test: /\.ts$/, loader: ts-loader, options: { appendTsSuffixTo: [/\.vue$/] } }, { test: /\.scss$/, use: [ process.env.NODE_ENV production ? MiniCssExtractPlugin.loader : style-loader, { loader: css-loader, options: { sourceMap: true } }, { loader: sass-loader, options: { sourceMap: true } } ] }, { test: /\.(png|jpe?g|gif|webp|svg|woff2?|eot|ttf)$/i, type: asset, parser: { dataUrlCondition: { maxSize: 8 * 1024 } }, generator: { filename: assets/[name].[hash:8][ext] } } ] }, optimization: { splitChunks: { chunks: all }, runtimeChunk: single }, plugins: [ new VueLoaderPlugin(), new MiniCssExtractPlugin({ filename: css/[name].[contenthash:8].css }), new HtmlWebpackPlugin({ template: public/index.html }) ] };vite这边// vite.config.ts import { defineConfig } from vite; import vue from vitejs/plugin-vue; import { fileURLToPath, URL } from node:url; export default defineConfig({ plugins: [vue()], resolve: { alias: { : fileURLToPath(new URL(./src, import.meta.url)) } }, css: { preprocessorOptions: { scss: { additionalData: import /styles/variables.scss; } } }, build: { assetsDir: assets, assetsInlineLimit: 8 * 1024, rollupOptions: { output: { manualChunks: { vue-vendor: [vue, vue-router] } } } } });顺便提一下很多新手从webpack迁移过来后会困惑SCSS的变量怎么在vite里没作用了。webpack里sass-loader有时会配合additionalData预先注入变量vite这边配置在css.preprocessorOptions.scss.additionalData二者的API是类似的但要注意vite里这里的字符串会直接拼在每个SCSS文件头部所以完全可以放import语句但别在里面放真正的样式定义否则每个scss文件都被复制一份产物体积猛涨。5.2 关键参数与文件输出位置的对比把两份配置放在一起看有几个地方是直接对位的需求webpack配置vite配置文件别名resolve.aliasresolve.aliasTS转译ts-loader / babel-loaderesbuild开发 rollup生产SCSS编译sass-loader内置自动调用preprocessorOptions资源内联阈值parser.dataUrlCondition.maxSizebuild.assetsInlineLimit静态资源输出目录generator.filenamebuild.assetsDir代码分割splitChunksrollupOptions.output.manualChunksCSS提取MiniCssExtractPlugin生产环境自动提取缓存文件名contenthash:8等默认[hash]按内容生成从这张表可以看出vite其实是在默认配置就合理的前提下把webpack里大量需要手工调优的东西内置了。webpack的配置自由度很高但每次升级或迁移都要重新翻文档这是它最重的地方。vite牺牲了一部分自定义能力换来的是开箱即用和心智负担大幅降低。5.3 构建产物对比实测我拿一个中等规模的Vue2项目大概30个路由组件、50个页面组件、若干图片字体资源分别用webpack5和vite的生产模式构建结果如下构建时长webpack约81秒vite约48秒提升大约1.7倍初次产物体积webpack约3.8MB未gzipvite约3.5MB未gzip相差不大分包数量webpack手动拆出5个chunkvite通过动态import自动拆出11个chunk冷启动开发服务器webpack 13.8秒vite 1.6秒文件修改后的HMR响应webpack大概350-500msvite 20ms以内。这些数据说明一个道理vite在生产构建上并不像开发环境那样有碾压性优势它的最大价值在开发体验。如果你的团队主要困扰是本地开发慢、HMR卡顿那vite是值得一迁的如果你只是追求更小产物体积那vite和webpack的差距并没有决定性的。6. 常见问题避坑指南6.1 webpack下文件处理的常见问题loader顺序错乱导致样式失效。比如use: [style-loader, sass-loader, css-loader]这种顺序sass-loader的输出直接进了style-loaderCSS的import和url()都没有被css-loader处理样式会乱、字体和图片路径会失效。记住这个核心顺序预处理语言loader在最后然后是css-loader处理完Javascript风格模块后再到style-loader或MiniCssExtractPlugin。图片base64阈值设置过大。我之前在一个老项目里看到有人把maxSize设置成100 * 1024结果所有100KB以下的图片全部内联成base64整个JS包膨胀了好几倍首屏加载严重变慢。合理阈值一般设置在4-10KB之间大图让它走独立文件路径。publicPath配置错误导致字体404。webpack里output.publicPath不仅影响HTML引用路径也直接影响asset/resources的获取路径。如果你部署到了子路径却没有改publicPath所有图片和字体都会以绝对路径斜杠开头404一片。解决方案是配置正确的publicPath或者使用相对路径publicPath: ./如果资源都在同一目录下。6.2 vite下文件处理的常见问题预构建缓存异常。第三方依赖改了版本后vite开发环境经常出现模块未找到、版本不符等报错此时删掉node_modules/.vite目录重启vite基本都能解决。这是因为vite预构建的结果是缓存的源依赖变化后它没法自动感知。如果你在monorepo里开发这个问题会更明显尤其是用pnpm workspace的场景记得在vite.config里加optimizeDeps.include来强制预构建某些包。老浏览器无法解析原生ESM。vite开发模式下完全不兼容老浏览器生产模式打包出来的代码也是ESM动态导入为核心的如果你的用户还停留在老旧浏览器需要加vitejs/plugin-legacy做降级处理它会生成一份SystemJS格式的兼容版打包文件。这里一定注意加了legacy插件之后产物体积会明显变大因为同一份代码要维护两套格式。SCSS全局变量在vite里失效。这个问题特别常见于从webpack迁移过来的项目。webpack里用sass-loader的additionalDatavite里就要用css.preprocessorOptions.scss.additionalData但要注意路径。很多时候你在SCSS里import /styles/variables.scss如果alias配置只在resolve里那scss的预处理器不一定能正确解析alias最好是用相对路径import ../../src/styles/variables.scss或者直接使用css.preprocessorOptions.scss.includePaths把src/styles目录加入查找路径。踩过几次坑之后我的习惯就是在vite里避免在scss里依赖alias统一用相对路径解决。大图片没有内联反而出现在dist里体积却超乎预期。vite默认内联阈值是4KB如果你有很多十几KB的小图标它们会全部按独立文件输出。你会发现构建产物里一堆小文件HTTP请求数反而增加了。此时把build.assetsInlineLimit调大到16 * 1024或者把所有小图标合成雪碧图能显著减少请求数。结尾一点个人体会把webpack换成vite最让我上瘾的不是那点冷启动速度而是文件处理逻辑变得通透了。webpack像一个大熔炉所有东西都丢进去熔炼规则复杂、配置繁琐但你对它掌控得越深越觉得它无所不能vite像一把手术刀开发环境里一切资源都被剥得干干净净它尽量让你写的就是浏览器认识的整个心智模型非常清爽。如果你的项目不需要太复杂的自定义构建逻辑我真心建议试试vite。迁移之前先把你webpack里那些奇技淫巧全部删掉所有的loader、plugin都换成最朴素的做法再用vite重写配置你会发现大部分情况下配置量直接少了一半。最后再分享一个小技巧无论你用哪个工具文件处理的核心永远是把项目里有多少资源、资源之间怎么引用这件事彻底理清楚工具只是帮你把这个关系落地的执行者理解这一点换哪个构建器都不慌。