2. 从“等得花儿都谢了”说起为什么传统构建越来越慢先坦白一个数据点。我手上有个中型后台项目组件大概 800 多个依赖里 axios、echarts、antd 这些一个不少。以前用 webpack 4 做开发服务器冷启动时间稳定在 40 秒开外如果电脑风扇不给力突破一分钟也不是什么稀奇事。而且这 40 秒只是“能打开页面”的时间真正要到首个页面完全可交互还得再加十几秒。一天改八个小时代码光等启动就浪费将近一集电视剧。这不是 webpack 不行而是它的核心设计思路在几年前还是最优解放到今天已经和前端项目的实际形态错位了。我见过不少团队把构建工具从 webpack 切到 Vite 之后最直观的感受不是“快了 20%”而是“怎么做到的首屏秒开”。很多人第一次接触 Vite 的时候都怀疑是不是自己电脑变好了或者项目变小了。都不是是架构逻辑变了。这篇文章我想把 Vite 这套“快”的底层逻辑掰开揉碎讲清楚包括它开发模式和构建模式的差异、依赖预构建的缓存机制、HMR 的实现路径以及我在实际项目里踩过的坑。不管你是刚接触 Vite 的新手还是准备把老项目迁到 Vite 的负责人搞清楚这些原理之后遇到问题才不会只靠百度重启大法。3. 传统打包器慢的根源一顿操作猛如虎结果只改了行 CSS3.1 打包思维的历史包袱webpack 的思路用一句话总结就是把你的整个应用当成一个巨大的依赖图从入口开始顺着 require 和 import 一路往下爬把所有的模块都找出来然后合并、压缩、拆分最终产出几个打包后的文件。开发环境下虽然没有压缩步骤但核心的“构建依赖图”这个动作是免不了的。这个动作的最大问题是它和你改了几行代码完全无关。你只是把按钮的颜色从蓝色改成红色但 webpack 依然要把整个项目的所有模块重新遍历一遍、重新解析一遍、重新组装一遍。这就像每次做菜之前都要把整个冰箱里的食材全部洗一遍切一遍哪怕今晚只炒一盘青菜。我做过一个粗略测试项目里 800 多个模块webpack 冷启动时Module build 阶段就要跑将近 20 秒这还是固态硬盘、16G 内存的机器。如果是机械硬盘或者内存紧张时间直接翻倍。而且 webpack 本身是用 JS 写的解析 AST、执行 loader、做 source map每一步都是 JS 在跑单线程的 EventLoop 再优化也扛不住海量模块的解析开销。另一个隐形杀手是 node_modules 的处理。webpack 会把 node_modules 里被打包进应用的依赖也一并纳入依赖图逐一解析。antd 的 index.js 可能引入了几十个组件每个组件又引了别的工具函数这些统统都要被 webpack 遍历到。依赖越多冷启动时间越呈非线性增长。3.2 一个关键观察浏览器早就支持 ES Module 了很多人在思考“为什么前端构建一定要先打包再运行”的时候忽略了一个背景变化现代浏览器原生支持 ES Module也就是script typemodule。这意味着浏览器自己能够处理 import 语句能够根据 import 的路径去服务器请求对应的模块文件。既然浏览器有这个能力为什么我们还要在开发环境里把所有模块先打包一遍再交给浏览器这就是 Vite 切入的核心角度开发模式下不做打包让浏览器自己按需加载。这种“省掉中间产物”的思路其实在工程领域很常见。好比以前从 A 地到 B 地没有直达车你必须先到中转站把所有行李重新装一次车再出发。现在 A 地到 B 地有直达班车了为什么还非要去中转站绕一圈当然事情没有这么简单。你不打包浏览器的确能直接请求 ES Module但开发环境下我们还需要处理 TS、JSX、CSS、静态资源、热更新这些东西。Vite 的真正难点不在于“不打包”而在于“不打包的情况下怎么把这些能力都提供好”。后面我会详细拆解。4. Vite 的两大核心引擎esbuild 和 Rollup各司其职4.1 开发服务器esbuild 负责“翻译”不负责“打包”Vite 开发服务器接收一个请求比如浏览器请求/src/App.vueVite 做的事情是用 esbuild 把这个 Vue 组件 TS 转成 JS、把 JSX 转成 JS、把模板编译成 render 函数然后把这个模块的源码原样返回给浏览器。这里的关键点是esbuild 只处理单个文件不做全量打包。它是用 Go 写的解析 TS/JSX 的速度比 Babel 快一到两个数量级。单文件的转换通常是毫秒级别的所以你编辑一个文件保存之后浏览器重新请求那个文件最多也就几十毫秒的延迟。很多人问过我一个问题Vite 为什么不直接用 esbuild 做生产打包而是用 Rollup答案是esbuild 的压缩和代码分割能力还不够成熟。它能把单文件转得飞快但是在处理复杂的代码分割策略、多种输出格式、插件生态方面Rollup 的成熟度高得多。可以这么理解esbuild 是一个快节奏的翻译官一对一翻译效率极高但临时拼接大场面还是得靠 Rollup 这种经验丰富的老导演来调度。我个人的实际经验是开发阶段用 esbuild 的“快”构建阶段用 Rollup 的“稳”。两者配合既保证开发体验又保证产物的质量和兼容性。4.2 依赖预构建把几百个小文件“搓”成几个大模块这里有一个非常关键的细节很多人容易忽略。浏览器虽然能直接加载 ES Module但它有一个性能短板如果某个依赖内部有几百个文件浏览器就得发几百个 HTTP 请求来加载这些文件。比如 lodash-es它把每个函数拆成一个文件总共有 600 多个模块。如果你直接在 HTML 里引用 lodash-es 的入口文件浏览器启动时会同时建立大量连接去拉取这 600 多个文件这个开销比打包一次还要大。Vite 的解决方案是依赖预构建在开发服务器启动之前扫描 node_modules 里所有被引用的依赖用 esbuild 把这些依赖统一打包成几个 ES Module 文件通常每个依赖包变成一个或几个文件。注意这里“打包”的对象是 node_modules 里的第三方依赖不是你自己写的业务代码。你自己的业务代码仍然保持按需加载。这个策略的聪明之处在于第一第三方依赖相对稳定很少频繁改动预构建一次的缓存可以长期复用。第二把几百个小文件合并成大文件浏览器的请求数大幅减少页面加载速度显著提升。第三预构建用的是 esbuild就算有 1000 个依赖文件要合并也只需要一两秒。我在项目里实测过Vite 冷启动的总时间里面依赖预构建大概占 1.5 秒左右业务代码零请求零处理。和 webpack 的 40 秒冷启动比起来这就是一个数量级的差距。4.3 monorepo 场景下依赖预构建的注意点去年我把一个 monorepo 项目迁到 Vite 时踩过一个坑子包之间通过 workspace 协议互相引用某个子包同时被多个业务包依赖。Vite 的依赖扫描器默认只扫描index.html直接引用的入口不会主动扫描 workspace 里其他子包的依赖。结果就是某些第三方依赖没有被预构建浏览器加载时出现大量请求启动速度反而变慢了。解决的办法是在 Vite 配置里用optimizeDeps.include显式声明需要预构建的依赖。举一个配置示例// vite.config.ts export default defineConfig({ optimizeDeps: { include: [your-scope/ui, echarts, lodash-es] } })这个配置也能解决另一个常见问题某些依赖由于动态 import 的方式不够静态化扫描器识别不到导致首次启动后页面报“Out of memory”或者直接白屏。显式声明是最省心的兜底方案。5. 一次模块请求的完整链路Vite 到底在幕后做了什么5.1 从 URL 到源码Vite 开发服务器的内部流程我觉得理解 Vite 最好的方式是跟随一次真实的浏览器请求来看它走了哪些流程。假设你的项目根目录下有index.html里面写着script typemodule src/src/main.ts然后浏览器发起了对http://localhost:5173/src/main.ts的请求。第一步Vite 开发服务器收到这个请求先做路径的标准化处理。比如把/src/main.ts解析到项目文件系统里的实际路径处理路径别名指向/src这类映射。第二步Vite 检查这个请求是否命中依赖预构建的缓存。如果命中直接返回缓存文件。这个缓存在项目的node_modules/.vite目录下可以在配置里通过cacheDir修改位置。第三步如果是业务源码文件Vite 会用 esbuild 转译。TS 语法转成 JSJSX 转成 JSVue 单文件组件会被拆成 JS、CSS、模板三部分分别处理。对于 Vue 文件Vite 内部会调用vitejs/plugin-vue完成 SFC 的编译。第四步Vite 会重写模块内部的 import 路径。因为浏览器只能发绝对路径请求而源码里可能写的是相对路径或者别名。Vite 会把import { ref } from vue改写成import { ref } from /node_modules/.vite/deps/vue.js?vxxxx。后面的?v是版本参数用于缓存失效控制。第五步把处理后的代码作为 JS module 返回给浏览器。浏览器拿到代码后再继续请求其中的 import 依赖于是上述流程对每个依赖模块重新执行一遍。整个过程是逐模块、按需执行的。你打开页面只加载当前页面依赖的模块而不是整个项目。这也是为什么项目越大Vite 的优势越明显。webpack 启动时是全量编译项目越大越慢Vite 启动时只处理浏览器实际请求到的模块项目再大首屏需要加载的模块数量也不会显著增加。5.2 路径重写一个赌上“性命”的细节这个流程里最容易让人困惑的环节是为什么 Vite 要重写你在源码里写的import路径你自己看的话import { defineConfig } from vue写法没问题浏览器也认识 import。但浏览器发起请求的时候它的 URL 是http://localhost:5173/vue对吧不对浏览器会把from vue解析成一个相对路径或者裸模块名bare module specifier它不知道vue对应的文件在哪。这就是为什么 Vite 需要把裸模块名转换成带完整路径的/node_modules/.vite/deps/vue.js。对于非依赖的模块重写则是把相对路径转换成以/开头的绝对路径。还记得前面提到的?v参数吗这个参数是 Vite 的缓存控制核心。依赖预构建完后Vite 给每个依赖文件挂一个 hash 值。当你新增或者升级某个依赖hash 变化浏览器会拿新的 URL 去请求旧的缓存自然就失效了不会出现“改了依赖但页面还是旧的”这种诡异问题。我刚迁移项目的时候曾经踩过一个相关的问题手动改了 node_modules 里某个包的文件Vite 没有意识到这个变化页面一直用旧缓存。排查了半天最后直接删掉node_modules/.vite目录重启解决了。现在想起来正确的做法应该是用vite optimize命令重新预构建或者升级依赖版本让 hash 变化。6. HMR 为什么能做到“保存即生效”原生 ESM 带来的热更新革命6.1 Webpack HMR 的链路为什么感觉没那么快论 HMR 的能力webpack 其实做得很好尤其是它和 React Fast Refresh、Vue HMR 的配合已经非常成熟。但问题在于webpack 的 HMR 也要经过“重新编译模块 — 打包成 chunk — 推送到客户端 — 客户端执行更新逻辑”这条链路。你可以留意一下webpack 的 HMR 在大型项目里经常会有 300-500ms 的延迟保存代码之后要等一会儿才看到页面变化。延迟的主体在“重新编译”。哪怕只改了一个组件webpack 也要对这个组件做一次完整的 loader 编译、AST 解析、依赖图谱更新。而这个动作在 HMR 场景下其实是每次都重新构建了一遍模块图里受影响的部分。Vite 的 HMR 实现是另外一个思路。它基于原生 ESM修改一个模块后Vite 服务器只需要做两件事第一用 esbuild 重新转换这一个文件第二通过 WebSocket 告诉浏览器“这个模块 changed请发送新请求”。浏览器收到通知后直接通过 import 请求最新的模块内容。由于 Vite 不需要重新打包任何 chunk也不需要对依赖图做全局刷新整个链路短得惊人。6.2 Vite HMR 的边界条件什么时候它会退化成全量刷新Vite 的 HMR 有一个边界条件值得一提不是所有修改都能走“局部热更新”路径。如果你修改的是 Vue 组件的 template 或者 styleVite 可以只替换渲染函数或者注入新样式页面状态完全不丢失。但如果你修改的是组件新增的 props 或者对外暴露的 APIVue 的 HMR 插件会检测到组件的签发生变化可能触发重新挂载状态就会丢失。更典型的情况是修改一个模块但它被很多其他模块依赖且没有明确的热更新边界Vite 会退化为页面全量刷新 reload。这在插件开发或者修改 store 全局状态时非常常见。我在项目中遇到过一个很折磨的问题修改pinia的 store 文件后整个页面总是重新加载状态全部清空。排查下来是 store 模块被很多组件间接引用Vue 的 HMR 规则认为直接替换这个模块的风险太高选择了全量 reload 兜底。这种情况不算 bug而是 HMR 设计上的一种取舍。理解了这个机制你就会明白为什么 Vite 官方文档建议把 HMR 边界设置好比如在组件内部通过import.meta.hot.accept显式声明热更新能力。if (import.meta.hot) { import.meta.hot.accept((newModule) { // 手动处理模块更新后的副作用比如清理定时器、重新注册事件 }) }平时做业务开发99% 的场景 Vite 自动 HMR 就够用。但如果你写的是一个自定义插件或者集成了某个非标准的运行时状态手动声明accept是唯一能保住状态的办法。6.3 dev 与 build 的 HMR 差异给新手的一个提示新手最容易踩的坑是开发环境下页面看起来一切正常一旦执行vite build就开始报各种错或者产物行为与开发环境不一致。原因很简单开发模式用的是 esbuild 加原生 ESM生产模式用的是 Rollup 打包。两条链路的转化能力完全不一样。esbuild 对某些 TS 特性和语法糖的支持更宽松Rollup 配合各种插件之后反而更严格。比如部分装饰器语法在 esbuild 下没问题但 Rollup 插件链里如果缺少对应的 babel 插件构建就会报 “Unexpected token”。同一套代码开发环境和生产环境走两套不同的编译通道这是 Vite 刻意为之的。开发环境要的是极致的启动速度和反馈生产环境要的是产物质量和兼容性。两个目标无法同时满足取舍才是合理的。所以我的建议是每次提交代码前至少跑一次vite build确认产物没问题不要只依赖开发模式的自测结果。7. 生产构建Rollup 在背后做哪些事7.1 为什么生产环境不能直接“不打包”跑 ESM前面讲了一大堆开发模式“不打包”的优势很多人自然会问生产环境能不能也这么干直接部署 ES Module 文件不打包浏览器一样能跑岂不是又少一步构建时间理论上可以但现实里的瓶颈很明显。第一浏览器的 ES Module 支持虽然已经相当普及但你还得考虑老版本浏览器尤其是某些还在维护的旧业务系统。生产环境不可能只照顾最新版 Chrome。第二不打包意味着最终部署的文件总数就是模块总数。一个 800 模块的项目部署 800 个文件每个文件都要做 HTTP 请求。如果模块小首屏要发几十个请求在弱网环境下体验非常糟糕。第三模块间的依赖关系如果不在构建期做静态分析运行期的加载错误更难排查。没有压缩、没有 tree-shaking、没有代码分割产物体积和加载时间都不可控。所以 Vite 的生产构建还是回到了“打包”这条路只不过选择 Rollup 作为打包器。这里有两个核心机制值得展开讲。7.2 Tree-shaking 和代码分割的实际配置Rollup 对 ES Module 的 tree-shaking 能力是业内公认的强。因为 ES Module 的 import/export 是静态结构编译器能明确知道哪些导出没有被引用从而在产物里把未引用的代码删除。曾经遇到过一种情况项目里用了 antd 的按需加载插件但是构建产物还是奇大无比。排查之后发现是代码里有人用import moment from moment而 moment 本身就是全量加载tree-shaking 对它基本无效。后来换成了dayjs体积直接少了约 40%。代码分割方面Vite 默认会基于动态 import 自动做代码拆分。比如你在路由配置文件里用() import(/views/Home.vue)Rollup 就会为每个路由生成单独的 chunk。这个机制能显著减少首屏加载量。如果想手动控制分割粒度可以在build.rollupOptions.output.manualChunks里配置export default defineConfig({ build: { rollupOptions: { output: { manualChunks: { vendor-react: [react, react-dom, react-router-dom], vendor-charts: [echarts] } } } } })我建议把 echarts 这类大体积、且只在部分页面用到的库单独拆成 chunk这样首屏只加载基础 vendor chunk用到图表再异步拉取 echarts chunk加载体验会好很多。7.3 产物兼容性的目标设置另一个容易踩坑的点是build.target。Vite 默认的构建目标是modules也就是支持原生 ES Module 的浏览器。如果你的业务需要兼容 Chrome 60 左右的老版本就得把 target 调低例如es2018。调低 target 会带来一个副作用Vite 会引入额外的语法转换和 polyfill产物体积变大构建时间变长。这属于标准的“兼容性换体积”的取舍需要项目负责人根据实际用户群体权衡。我的经验是如果产品面向 ToB 企业客户永远要留一手兼容性如果面向 C 端且用户以主流浏览器为主可以放心用默认的modules。8. 实操中的常见问题和排查技巧一个老司机的速查手册8.1 依赖预构建缓存引发的“改了依赖却不生效”现象升级了某个 npm 包的版本代码里也能看到新版本的 API 提示但跑起 dev server 之后浏览器里还是旧文件。排查思路第一看地址栏里模块 URL 的?v参数是否变化。没变说明 Vite 没有检测到依赖变化还在用旧的预构建结果。第二手动清除缓存目录删掉node_modules/.vite然后重启 dev server。第三检查 package.json 里的 lock 文件是否真的更新了有些情况是npm install没执行干净。如果这个依赖是 workspace 里的本地包注意 Vite 对本地链接包的监听规则和普通依赖不同推荐在optimizeDeps.include里显式声明。8.2 断点调试失效的奇怪问题我在 Vite 项目里遇到过DevTools 里 sourcemap 明明生效了能定位到源码位置但断点老是打不中。排查后发现是 Vite 的 sourcemap 默认配置build.sourcemap在开发模式下是可以正常提供的问题出在项目用了vitejs/plugin-legacy低版本浏览器兼容模式下sourcemap 的处理链路会变得复杂。遇到这种情况建议做两件事第一确认浏览器版本支持原生 ESM第二在 vite.config.ts 里显式声明build.sourcemap: true并关闭某些插件的 sourcemap 干扰选项。对大多数开发者来说直接在最新版 Chrome 和 Edge 上调试是最省心的方案老浏览器的兼容性验证放到生产环境再说。8.3 Node 版本和依赖冲突类问题速查报错信息片段常见原因处理方式Cannot find module vite依赖没装完或版本不匹配删除 node_modules 和 lock 文件重新安装The CJS build of Vites Node API is deprecated项目里有 CJS 格式的配置文件改名为 vite.config.mjs 或使用 defineConfig 且保持 ESM 格式[plugin:vite:dep-scan]相关报错依赖扫描阶段某个依赖解析失败在 optimizeDeps.include 中显式声明该依赖Could not resolve某路径路径别名配置缺失或路径写错检查 resolve.alias 和实际文件路径(Emitted value instead of an instance of Error)vue 模板编译出错精确定位到出错的 SFC 文件查看模板部分语法最后一个我自己犯过的低级错误把vite.config.ts写成了vite.config.js结果项目里 TypeScript 相关配置全部不生效报错信息七绕八绕。后来统一所有项目都用 TypeScript 格式的配置文件再也没被这种低级问题浪费时间。8.4 老项目迁移到 Vite 的取舍和注意点如果你准备把一个 webpack 老项目迁到 Vite我最大的建议是不要追求一次性 100% 迁移成功分两步走。第一步先把 dev 环境切到 Vite。把 webpack 的 loader 配置对应到 Vite 插件比如 sass、less、图片处理、环境变量注入这些 Vite 都有对应的现成插件。dev 环境迁移完成后先跑一段时间确认日常开发没有阻塞问题。第二步再处理生产构建。因为生产构建涉及产物 hash、CDN 路径、按需加载、骨架屏注入等细节一步到位风险很高。建议先产出一次对比包检查产物体积和加载性能有没有明显劣化再用灰度方案逐步切流。我主导过的两个 Webpack 老项目迁移都是这个节奏。最终迁移完成之后开发启动时间从 40 秒降到 3 秒以内团队反馈非常正向前面折腾配置文件的白头发也算值了。9. 我的个人体会和一些收尾的小建议说实话从 webpack 切到 Vite最让我感慨的不是“快”而是“思路的转变”。webpack 假设浏览器是不聪明的需要把所有东西嚼碎了喂到嘴边Vite 则信任现代浏览器的原生能力只把开发环境里需要补充的“翻译”工作做好。这种信任换来的收益是巨大的更短的反馈循环、更少的等待焦虑、更干净的调试体验。对于需要频繁调样式、试交互的开发者来说开发环境的响应速度直接决定了一个人的心流能维持多久。从实操层面最后再分享一个小技巧如果你想让 Vite 的启动速度再快一点可以在vite.config.ts里开启server.open让它启动后自动打开浏览器同时把系统的 DNS 解析和端口占用处理好避免每次启动前都被 “port already in use” 打断。另外Vite 官方提供的create-vite脚手架本身足够轻量但大型项目通常还需要补上 ESLint、Prettier、路径别名、环境变量校验、单元测试框架这一整套工程化设施。这些配置不会出现在任何教程里得靠团队自己根据项目体量逐步沉淀。说到底工具只是手段效率才是目的。Vite 的出现并没有改变 JavaScript 模块化的本质它只是把构建工具放回了“服务于开发者”的正确位置。至于未来还会不会出现比 Vite 更快的方案Borderline、Rspack、Turbopack 都在抢这个赛道。但至少在当下Vite 的这套“按需加载 预构建 高性能转译”的组合拳依然是开发体验最优的答案之一。希望这篇文章能帮你在实际项目中少踩几个坑多一点写代码的时间。