文章目录前言一、先说结论Vite 和 Webpack 本质差在哪1.1 Webpack 的思路1.2 Vite 的思路二、Vite 为什么开发环境快2.1 浏览器原生 ESM2.2 首次启动为什么更快2.3 HMR 为什么更快三、依赖预构建是什么3.1 为什么 node_modules 不能直接裸跑3.2 Vite 的做法预构建3.3 为什么是 esbuild不是 Rollup四、Vite 生产环境为什么不用 esbuild 直接打包4.1 开发快不代表产物控制最强4.2 Vite 的生产构建链路4.3 一个最小的 Vite 配置五、Webpack 的优势还在不在5.1 Webpack 的核心优势生态成熟定制能力强老项目迁移成本低5.2 Vite 并不是“全面替代”六、Vite 与 Webpack 的核心对比6.1 开发模式对比6.2 生产模式对比6.3 心智模型对比七、从配置角度看差异7.1 Vite 配置更偏“声明式”7.2 Webpack 配置更偏“组装式”八、典型场景怎么选8.1 适合优先选 Vite 的场景8.2 适合继续用 Webpack 的场景8.3 一个现实建议九、面试聚焦9.1 Vite 为什么开发环境快9.2 Vite 生产为什么用 Rollup不直接用 esbuild9.3 Vite 能完全替代 Webpack 吗十、易混淆点十一、思考与练习总结前言提到前端工程化很多人第一反应还是 Webpack但这几年新项目里Vite 几乎成了 Vue 3、React、Svelte 的默认选项。原因不只是“它快”更关键的是它在开发环境和生产构建上走了和 Webpack 不同的路线。本篇聚焦Vite 的工作原理与它和 Webpack 的核心差异讲清楚Vite 在开发环境为什么启动快、更新快Vite 生产构建为什么仍然要打包Vite 与 Webpack 各自适合什么场景一、先说结论Vite 和 Webpack 本质差在哪最容易记的一句话是Webpack开发和生产大多都围绕“先打包再运行”Vite开发时尽量“不打包”生产时再交给 Rollup 打包也就是说两者最大的区别不是配置文件长短而是dev 与 build 的处理路径不同。1.1 Webpack 的思路Webpack 会从入口文件出发分析依赖经过 loader 转换后生成模块图再输出 bundle。Entry - 依赖分析 - Loader 转换 - Chunk - Bundle - Dev Server / Dist不管是开发环境还是生产环境Webpack 的核心模型都是“构建 bundle”。1.2 Vite 的思路Vite 把场景拆成两部分开发环境浏览器直接加载原生 ESMVite 只做按需转换和请求分发生产环境交给 Rollup 真正打包输出开发浏览器请求模块 - Vite 按需编译并返回 ESM 生产源码 - Rollup 打包 - 产出 dist这就是为什么很多人说Vite 是“开发体验优化器”Rollup 是“生产构建器”二、Vite 为什么开发环境快2.1 浏览器原生 ESM现代浏览器已经支持 ES Module所以 Vite 开发时不需要像 Webpack 一样先把整个项目打成一个 bundle 再让浏览器执行。例如页面里有这样一段代码import{createApp}fromvueimportAppfrom./App.vueimport./styles/index.csscreateApp(App).mount(#app)在 Vite dev 模式下浏览器会发起多个模块请求/src/main.ts/src/App.vue/src/styles/index.css/node_modules/.vite/deps/vue.js也就是说Vite 更像一个“按需返回模块的开发服务器”而不是一个先把所有东西捆成一个文件的打包器。2.2 首次启动为什么更快Webpack 启动 dev server 时通常要先做这些事找入口扫描依赖跑 loader构建模块图生成初始 bundle项目越大第一次启动越慢。Vite 的首次启动则更轻先启动一个 dev server扫描入口 HTML 和源码依赖对源码模块按请求即时编译对第三方依赖做一次预构建缓存所以你会感觉它“秒开”原因不是完全没做事而是把一大块成本从启动时拆到了请求时。2.3 HMR 为什么更快Webpack 在模块变更后虽然也支持 HMR但更新路径往往要经过更完整的模块图处理。Vite 的 HMR 更接近找到变化的模块只失效相关模块通过 WebSocket 通知浏览器浏览器重新请求这一个模块如果改的是一个 Vue 单文件组件通常只会重新编译这个.vue文件对应的模块而不是重新处理整张大图。所以实际体验上Vite 在以下场景会特别明显页面数量多组件文件多样式频繁改动中后台项目模块复杂三、依赖预构建是什么3.1 为什么 node_modules 不能直接裸跑源码模块通常是你自己写的 ESM但node_modules里的第三方包未必都适合浏览器直接高效加载。典型问题有两个包格式不统一有 CommonJS、UMD、ESM 混合情况依赖过碎一个库可能内部再引用几十上百个文件请求数量很多如果开发环境直接把这些依赖原样交给浏览器体验反而会变差。3.2 Vite 的做法预构建Vite 启动时会扫描依赖把第三方包预先处理到node_modules/.vite目录里。它主要做两件事把 CommonJS 等格式转换成 ESM把零散依赖合并、缓存减少浏览器请求数这里常用的是esbuild因为它做这类转换非常快。node_modules 原始依赖 ↓ scan esbuild 预构建 ↓ cache node_modules/.vite/deps3.3 为什么是 esbuild不是 Rollup因为预构建的目标是快速足够好面向开发环境esbuild 在速度上非常有优势非常适合做依赖扫描和预构建但到了真正生产打包时Vite 还是选择 Rollup 来换取更成熟的产物控制能力。四、Vite 生产环境为什么不用 esbuild 直接打包这也是面试里很常见的问题。4.1 开发快不代表产物控制最强esbuild 的优势主要是速度但生产构建不只看速度还看chunk 拆分能力插件生态成熟度Tree-shaking 稳定性多格式产物支持产物细粒度控制Rollup 在这些方面更适合做最终产物生成。4.2 Vite 的生产构建链路源码 - Vite 插件处理 - Rollup 打包 - dist所以要记住Vite dev 快靠浏览器原生 ESM esbuild 预构建Vite build 稳靠 Rollup 输出生产包4.3 一个最小的 Vite 配置// vite.config.tsimport{defineConfig}fromviteimportvuefromvitejs/plugin-vueexportdefaultdefineConfig({plugins:[vue()],server:{port:5173},build:{sourcemap:false}})这也是 Vite 常给人“配置少”的原因之一很多开发体验是它内建提供的而不是像 Webpack 那样大量依赖 loader 组合。五、Webpack 的优势还在不在当然在而且很多时候还很强。5.1 Webpack 的核心优势生态成熟Webpack 发展多年loader、plugin、历史项目经验都非常丰富。很多老项目、复杂项目、深度定制项目仍然以 Webpack 为基础。定制能力强如果项目里有很多历史包袱例如特殊 loader 链老式模块系统兼容微前端改造多页面、非标准输出流程深定制构建插件Webpack 往往更容易承接这些复杂需求。老项目迁移成本低一个已经跑了几年的大型 Webpack 项目不一定值得为了“启动更快”就整体迁到 Vite。迁移成本包括构建链替换插件兼容性验证CI/CD 调整团队习惯迁移5.2 Vite 并不是“全面替代”更准确的说法应该是新项目优先考虑 Vite老项目评估收益后再决定是否迁移极复杂工程链路Webpack 仍可能更合适工程化工具不是新旧之争而是场景匹配。六、Vite 与 Webpack 的核心对比6.1 开发模式对比对比项ViteWebpack开发启动借助原生 ESM通常更快先构建模块图与 bundle通常更慢HMR精确到模块级失效更新快也支持 HMR但大型项目更新成本更高依赖处理esbuild 预构建 缓存loader/plugin bundle 流程源码请求浏览器按需请求模块dev server 提供打包结果6.2 生产模式对比对比项ViteWebpack生产打包默认基于 Rollup原生基于 Webpack 自身配置复杂度通常更低通常更高但也更细产物控制借助 Rollup能力强生态成熟能力也很强历史项目适配新项目更友好老项目更常见6.3 心智模型对比如果你想快速记忆可以这样理解Webpack一个全能型构建平台Vite一个把“开发体验”和“生产打包”拆开的现代工具七、从配置角度看差异7.1 Vite 配置更偏“声明式”// vite.config.tsimport{defineConfig}fromviteimportvuefromvitejs/plugin-vueexportdefaultdefineConfig({plugins:[vue()],resolve:{alias:{:/src}},server:{proxy:{/api:{target:http://localhost:8080,changeOrigin:true}}}})很多常见需求比如Vue 支持路径别名本地代理环境变量在 Vite 里都更接近“直接声明需求”。7.2 Webpack 配置更偏“组装式”// webpack.config.jsconstpathrequire(path)constHtmlWebpackPluginrequire(html-webpack-plugin)module.exports{entry:./src/main.js,output:{filename:bundle.js,path:path.resolve(__dirname,dist)},module:{rules:[{test:/\.vue$/,loader:vue-loader}]},plugins:[newHtmlWebpackPlugin()],devServer:{proxy:{/api:http://localhost:8080}}}Webpack 不是不能做而是你通常需要更明确地把“处理链”组装出来。八、典型场景怎么选8.1 适合优先选 Vite 的场景Vue 3 / React 新项目中后台系统、管理台、组件化项目团队希望降低本地开发等待时间需要更轻量的配置体验8.2 适合继续用 Webpack 的场景已稳定运行的大型老项目强依赖自定义 loader/plugin 的项目构建链条非常复杂、迁移成本高团队已有成熟 Webpack 工程基建8.3 一个现实建议如果你是新开项目优先用 Vite维护存量项目先优化现有 Webpack再评估迁移收益准备面试既要懂 Vite 为什么快也要理解 Webpack 的 bundle 模型九、面试聚焦9.1 Vite 为什么开发环境快核心原因有三点利用浏览器原生 ESM开发时不需要先整体打包源码模块按需编译、按需返回第三方依赖通过 esbuild 做预构建与缓存9.2 Vite 生产为什么用 Rollup不直接用 esbuild因为生产构建除了速度还需要更成熟的 chunk 控制、插件生态、Tree-shaking 与输出能力Rollup 在产物质量和控制力上更适合生产场景。9.3 Vite 能完全替代 Webpack 吗不能一概而论。新项目很多可以直接选 Vite但老项目、特殊 loader 链、复杂工程体系下Webpack 依然很有价值。十、易混淆点Vite 不是完全不打包它只是开发时尽量不打包生产环境仍然要打包。Vite 快不等于所有场景都更优复杂历史项目迁移成本可能很高。esbuild 不等于 Vite 全部esbuild 主要负责预构建和部分转换生产打包核心仍是 Rollup。原生 ESM 快的前提是现代浏览器环境这也是 Vite 更偏现代前端工程链路的原因。Webpack 慢是相对的小项目下差异未必巨大大项目下体验差距更明显。十一、思考与练习1.为什么说 Vite 把开发和生产拆成了两条链路解析开发阶段基于浏览器原生 ESM 与按需编译生产阶段交给 Rollup 打包两者目标不同所以实现方式也不同。2.依赖预构建解决了什么问题解析把第三方依赖统一转成更适合浏览器处理的 ESM并减少碎模块请求数量提升开发启动与页面加载效率。3.为什么 Webpack 在老项目中仍然常见解析生态成熟、定制能力强、历史包袱多、迁移成本高很多项目继续使用 Webpack 更现实。4.面试里如果被问“Vite 为什么快”最少要答哪几点解析原生 ESM、按需编译、依赖预构建、HMR 更新范围更小。5.什么场景下不要轻易把 Webpack 项目迁到 Vite解析当项目已经稳定、构建链复杂、插件依赖深、迁移收益有限时不应只因“新”就贸然迁移。总结核心差异Webpack 偏向统一 bundle 模型Vite 把开发与生产拆开处理Vite dev 快原生 ESM、按需编译、依赖预构建、HMR 粒度更细Vite build 稳生产构建依赖 Rollup而不是完全靠 esbuildWebpack 仍有价值生态成熟、适合复杂和存量工程选型原则新项目多选 Vite老项目看迁移成本与收益不做绝对判断
