企业官网建设流程全解析

你要说 Vite 快，我第一个反应是：启动是真的快。第一次在项目里跑npm run dev，终端命令行刚敲完，还没来得及喝口水，浏览器标签页就自己弹出来了，地址栏显示 localhost:5173，页面上的组件已经开始在渲染。换做之前的 Webpack 项目，这时候大概率还在看进度条。不过快归快，真正把它放进中大型项目里，各种怪毛病也接踵而来：process is not defined、Buffer 没定义、局域网手机访问直接白屏、甚至打包的时候比开发慢了好几个数量级。这篇东西不打算给你讲一堆面试题式的官话，我想从我自己从 Webpack 迁移到 Vite、又踩过若干热搜坑之后的理解，聊聊 Vite 到底快在哪，为什么快，有哪些注意不到的地方，以及遇到那些高频报错时应该怎么处理。

1. 从 Webpack 到 Vite：开发服务器“慢”在哪

1.1 打包器只做三件事：解析、转换、打包

任何现代前端构建工具，核心都可以拆成三件事：解析模块依赖、把非标准模块转换为浏览器能识别的代码、把众多模块合并成可加载的文件。Webpack 在启动开发服务器时，会从入口开始递归遍历项目中所有 import 和 require，解析每个模块的依赖关系，然后交给对应的 loader 处理，最终生成一个 bundle 供浏览器加载。这个过程你没得选，它必须先把整张依赖图完整构建出来，哪怕你只改了其中一个 Button 组件，启动时也要重新经历一遍全量扫描。项目规模越大，依赖节点越多，耗时就越明显，这不是 Webpack 的 bug，而是“先打包后运行”模型的天然代价。

如果你用过大型项目，一定对那种感受有记忆：编辑器里代码写好了，切回浏览器，页面还在转圈。改一行样式，热更新也要等两三秒。这些都不是个例，而是构建模型决定的。Webpack 的开发服务器其实很强大，但它默认的做法是“把所有东西都先处理完，再告诉浏览器可以开始”，所以项目越大，冷启动越慢，热更新也会被全量编译的尾巴拖住。

1.2 Webpack 开发服务器的冷启动困境

我印象最深的一次是在一个 React 老项目里跑webpack-dev-server，刚拉完代码，冷启动大概花了二十多秒，一旦中间遇到编译错误，改完了还要再等一轮。有人会说我用的是 Webpack 5 的持久化缓存，冷启动会快一些，但缓存目录失效的场景太多了：换分支、新装依赖、升级依赖版本、重新 clone 代码，都会导致缓存重新构建。就算缓存命中的时候能压到三四秒，也远远谈不上“秒开”。实际上对大多数项目而言，Webpack 的编译瓶颈不在 CPU 能力，而在于它把整个应用当成一个整体来构建，数据量和编译动作都很大。

更麻烦的是，Webpack 启动阶段做的一大堆事情里，很多与“当前页面到底用到什么”无关。你打开的是登录页，但它仍会把后台管理系统里七弯八绕的路由、图表库、表格组件全部扫描并注册一遍。这种“宁可多算，不可漏算”的保守策略，换来了极高的兼容性，代价就是速度。所以不是 Webpack 不努力，而是它选择了一条生产环境很稳、开发环境却很重的路。

1.3 Vite 换了一条路：浏览器就是打包器

Vite 之所以能在开发环境做到快，最简单的一句话就是：它把“打包”这件事从开发服务器身上挪走了，交给了现代浏览器。浏览器原生支持 ES Module 之后，你可以在 HTML 里写<script type="module">，也可以通过import动态加载模块。这意味着开发阶段根本不需要预先打包整个应用，只需要 Dev Server 启动时做一些准备工作，然后等浏览器实际请求某个模块时，再单独编译返回那一个模块。

Vite 的架构非常聪明：开发态的核心是浏览器和 Dev Server 之间的按需传输，浏览器负责模块请求，Vite 负责解析和转换。冷启动时间不再取决于整个项目的模块数量，而取决于依赖预构建的数量和 Dev Server 本身的启动速度，这个量级完全不一样。以前是“满汉全席提前做好一大桌，客人来了直接上菜”，Vite 是“客人点一道菜，厨师做一道”。后者的启动体验自然轻快得多。

2. Vite 速度的三驾马车：ESM、预构建与缓存

2.1 原生 ESM 的“按需加载”原理

为什么原生 ESM 能带来这么大的速度变化？直接看浏览器行为。你在代码里写import { ref } from 'vue'，浏览器加载这段代码时，会向 Dev Server 发出对/node_modules/.vite/deps/vue.js的请求，然后把这个模块作为依赖加载。同样，SFC 文件、TS 文件、CSS 文件，在开发阶段都是浏览器发起请求后才被编译并返回。也就是说，一个几千个组件的大项目，开发时用户打开首页，浏览器只会请求首页实际用到的几十个组件，剩下的组件即使存在，也不会触发编译。

这个模型天然就是按需的，和“无论用没用到都先全部打包”的 Webpack 有本质区别。你可以把它类比成餐厅做菜：客人点一道菜，厨师做一道，而不是提前把菜单上所有菜都做一遍。这也是为什么 Vite 官方文档反复强调“原生 ESM 是 Vite 开发体验的核心”的原因。理解了这一点，后续很多优化方向都会清晰起来：让页面尽量做按需加载，减少首屏模块数；避免在源码里同步 import 大量无关工具，这些都会直接影响 Dev Server 的实时编译量。

2.2 esbuild 预构建：为什么必须预构建 node_modules

这里有一个细节需要解释：浏览器能够直接加载 ESM，但node_modules里的包通常长什么样？大量第三方包还是 CommonJS 格式，也就是用require和module.exports。浏览器不认识这种语法，而且很多包导出的入口文件分散在多个子路径里，直接让浏览器按源码 import 会爆发大量请求，每个包的一堆内部文件都要发一次 HTTP 请求，性能会很差。

于是 Vite 在启动时用 esbuild 对依赖做“预构建”：把 CommonJS/UMD 转换成 ESM，把多个内部文件统一到一个或少数几个文件里，再放到node_modules/.vite/deps目录下。esbuild 用 Go 实现，可以并行利用多核 CPU，转换速度比传统 JS 实现的打包器快几十倍，这才是 Vite 冷启动快的第二个关键因素。你在启动日志里看到的 “Optimizing dependencies” 就在做这件事。这个过程通常非常短，因为依赖数量远小于整个应用源码数量，而且 esbuild 本身就是为极致性能设计的。

2.3 缓存策略：依赖缓存与浏览器强缓存

预构建的产物不是每次都重新生成的。Vite 会根据 lockfile、配置文件、依赖版本等信息计算一个 hash，存到node_modules/.vite/deps/_metadata.json。只要这些信息没变，下次启动会直接从缓存加载，不重复预构建。这也是为什么你新装了一个包，或者改变了 optimizeDeps 配置之后，Vite 会提示你“重启并清空缓存”。另一方面，源码文件走的是 304 协商缓存，判断内容是否有变化；预构建后的依赖走的则是强缓存，Cache-Control: max-age=31536000,immutable。因为依赖版本不变，就可以一年内不重新请求。这套缓存组合保证了热更新和刷新页面时，重复请求的开销几乎为零。

实际操作中，很多人会遇到“改了代码但页面没变化”“改了依赖配置但没生效”的情况，多半就是缓存没有正确失效。这时候不要急着怀疑 Vite 有问题，先看依赖缓存目录是否被锁住，或者强制开启server.force重启开发服务器，通常能解决大部分“公主病”。

2.4 按需编译：Vite 只转换被请求的模块

预构建搞定的是依赖，应用源码本身并不在启动时转换。Vite 针对.vue、.ts、.tsx、.css等文件的编译，都是被浏览器请求时才触发，而且编译结果会缓存起来。一个很直观的现象：在 Vite 项目里，启动速度和你写的组件数量没有线性关系，更多取决于首屏涉及的范围。如果你在 App.vue 里只 import 了两个组件，其他一千个组件只是躺在项目里，启动后根本不会被编译。

这个特性和 Webpack 的“先全量编译、再提示成功”完全不同。因此，如果你觉得 Vite 启动变慢了，不要只盯着 Vite 本身，先检查是不是入口文件里直接或间接关联了太多模块。一个把所有路由都用静态 import 引入的项目，首屏等于加载了整个应用，按需编译这个优势就会大打折扣。我见过不少项目迁移到 Vite 后体验不够好，原因不是 Vite 不行，而是源码结构根本不适合按需加载：入口文件巨大的单 store、全局疯狂引入的公共组件、没有做路由懒加载，这都会把压力从“启动阶段”转移到“首屏请求阶段”。

3. 生产构建为什么是另一套逻辑：Rollup 与 esbuild 的分工

3.1 开发快不代表打包快：Vite build 的真相

很多人第一次用 Vite 会发现一个反差：开发环境快到起飞，但vite build有时候并没有想象中那么快，甚至还会被吐槽“打包太慢”。这是正常的，因为开发环境的目标是“尽快把单个模块返回给浏览器”，生产环境的目标是“产出尽可能小、加载最高效、兼容性更好”的静态资源。这需要做依赖合并、代码分割、Tree Shaking、CSS 提取、资源指纹等大量工作。

Vite 在生产构建时并没有沿用开发态的按需传输逻辑，而是选择 Rollup 作为核心打包器。Rollup 是一个经过大量项目验证的打包器，插件生态丰富，输出的代码质量高，能处理复杂的动态 import 和 chunk 拆分场景。esbuild 虽然转换速度快，但在深层优化和代码生成的可定制性上还不够成熟，所以 Vite 让 esbuild 负责压缩和部分转换，真正的“组织打包”交给了 Rollup。这个分工不是偷懒，而是各取所长。

3.2 为什么还是会有人说“vite打包太慢”

说实话，Vite 构建的瓶颈通常不在 Vite 本身上，而在于你怎么用它。常见慢的场景：项目中引入了超大第三方库，比如包含大量语言的 Moment.js、包含整个可视化能力的图表库，这些库在 Rollup 阶段做 Tree Shaking 时成本极高；或者你开启了 sourcemap，每一个文件和模块都生成一份映射表，体积和耗时都会明显上升；又或者大量静态资源走的是 base64 内联，转成字符串体积爆炸。

另外，如果你的项目是从老 Vue CLI 项目迁过来的，构建脚本里还带着一堆 babel 插件、eslint 校验步骤，每个阶段都在拖后腿。建议先检查这些点，再判断是不是 Vite 本身的问题。我见过一个项目，vite build要 40 秒，打开 sourcemap 后直接变成 3 分钟，关掉之后又回到 40 秒，这就是典型配置问题，而不是构建器慢。

3.3 针对生产构建速度的几个实操手段

有几个立竿见影的操作。第一，不需要线上调试时，把build.sourcemap关掉。第二，合理配置build.rollupOptions.output.manualChunks，把体积大又不常变的第三方库单独拆 chunk，避免每次构建都做无意义的重复合并。第三，升级到较新版本的 Vite，一直以来构建性能都有持续改进。第四，如果项目里存在多个框架运行时，可以考虑用依赖预打包工具，把大量依赖提前打包成 chunk。

另外，生态里也出现了一些新的构建器方向，比如 Rspack、Rolldown，都是为了解决构建速度这个核心问题。这说明整个社区都在关注构建性能，也说明“Vite 打包慢”并不是一个不可解的难题。对大多数项目来说，Rollup 的打包时间已经在可接受范围内，真正需要担心的是那些巨型依赖和不合理的配置，而不是打包器本身。

4. 那些“Vite 报错”热搜背后的原理

这里先说一个整体判断：Vite 的开发态之所以轻快，某种程度上是因为它“不惯着” Node 环境的老毛病。它默认就是一个浏览器优先、ESM 优先、标准优先的构建器。也正因为这样，那些经常上热搜的报错——process is not defined、Buffer 不识别、局域网白屏——其实都和这套轻快的架构有关。理解了背后的权衡，你才能既享受它的快，又不在报错面前手足无措。

4.1 process is not defined：浏览器环境没有 Node 全局变量

这个报错出现的频率非常高，尤其当项目里有老代码或第三方包依赖process.env.NODE_ENV时。原因是 Vite 在浏览器环境里不会帮你注入 Node.js 的process全局对象，而 Webpack 在开发环境通常会塞一个 polyfill。所以一运行就报process is not defined，然后一堆人搜解决方案。最简单的做法是别跟它对着干，在 Vite 配置里用define把需要的变量替换掉，比如：

// vite.config.js export default { define: { 'process.env.NODE_ENV': JSON.stringify('production') } }

但这只解决表面问题。更推荐的方式是改用 Vite 自带的import.meta.env，这才是面向 Vite 的标准环境变量写法。如果你的node_modules里某个依赖必须读 process，那你得先定位到具体包，再决定是 alias 替换，还是加 polyfill。不要见一个报错就全局塞一个 define，那样只会把真正的依赖问题藏住。

4.2 不识别 Buffer：polyfill 为什么默认不提供

类似 process 的还有 Buffer。很多老库在浏览器里直接使用Buffer.from，但浏览器原生并没有这个名字，于是报错。Vite 默认不会像 Webpack 4 那样给你自动 polyfill Node 的核心模块，因为 Node 的 polyfill 大多体积大、容易误导，而且会让浏览器加载一堆根本用不到的代码。真正碰到这种问题，我会先查是哪层依赖在用 Buffer：是业务代码还是 node_modules。如果是业务代码，换更现代的 API 通常就能解决，比如用TextEncoder处理字符串编码；如果必须兼容老库，再考虑安装vite-plugin-node-polyfills，或者针对特定模块做 alias 指向buffer包的 polyfill。不建议直接全量注入所有 Node polyfill，那会把构建体积撑大，也把浏览器性能拖垮。这个原则和 Vite 的开发哲学是一致的：默认不做多余的事，只在确有必要时补上。

4.3 局域网打开空白：ESM、host 配置与浏览器缓存

这个热搜词“vue3 vite dev 局域网打开空白”确实经常出现。默认情况下，Vite 的 dev server 只监听 localhost，你让同一局域网里的手机或同事电脑通过 IP 访问，自然连不上，所以要先在配置里设置server.host: true，让它监听所有地址。但这里有一个经常被忽略的坑：即使 host 改好了，Vite 生成的模块 URL 可能会基于用户请求的 Host 去构造，如果手机浏览器访问时用的 IP 没问题，但某些内嵌资源仍然指向 localhost，就会白屏。必要时需要设置server.origin，或者在开发时干脆统一通过电脑的 IP 访问页面，避免资源路径错乱。

另一个常见诱因是浏览器缓存了旧版预构建依赖或旧的 chunk URL，导致新的页面加载失败。这种时候重启 dev server，必要时强制--force清缓存，就能恢复。局域网白屏的排查顺序建议是：先看 Dev Server 是否真的返回了 HTML，再看浏览器 Network 里哪个请求失败，最后查控制台的报错。这一步一步来，比一手抓瞎高效得多，也能避免你误把 Vite 的速度优势当成“不稳定”。

4.4 xlsx-style、xdg-open 等生态兼容问题怎么看

继续顺着热搜词说。vite 使用 xlsx-style能上热榜，原因就是 xlsx-style 是一个非常老的 Excel 导出库，它的代码里引用了大量 Node 内置模块，比如 fs、path、crypto 之类。浏览器环境根本没有这些模块，直接引入必报错。这类问题本质上不是“Vite 不支持”，而是“这个库本来就不是为浏览器设计的”，你需要的是兼容层或者换替代品。

再看vite xdg-open，这其实是 Linux 上 Vite 自动打开浏览器时调用了xdg-open命令，某些极简桌面环境没装这个命令，或者没有关联程序，就会报错。它和 Vite 的性能与架构无关，只是环境配置的一部分。理解了来源，就不会被它带到沟里去。面对这些报错，我的经验是先判断它属于“模块兼容”还是“环境命令”，再决定是否配置 alias、polyfill 或放弃某个库。很多问题不是 Vite 造成的，而是你把 Node 世界的习惯带进了浏览器世界。

5. 实测思路：如何让 Vite 在项目里真正跑得快

5.1 按需优化依赖预构建：include/exclude 怎么配

Vite 启动时会自动扫描项目里 import 的依赖并预构建，但自动扫描不是万能的。比如动态 import 的变量路径、monorepo 里通过 workspace 引用的本地包、或者某些通过import()加载的插件，都有可能不会被自动发现，导致运行时 esbuild 临时再预构建新依赖，于是你在“加载某个页面时突然卡一下”。这时候可以在optimizeDeps.include里把这些依赖显式列出来，让它们在启动阶段一次性完成预构建：

export default { optimizeDeps: { include: ['lodash-es', 'some-lib', 'another-dynamic-dep'] } }

相反，如果你的某个依赖已经提供了标准 ESM 输出，而且不需要预构建，可以在optimizeDeps.exclude里排除，减少预构建负担。这里有一个很实用的技巧：打开 Vite 的 debug 日志，设置环境变量DEBUG=vite:deps，就能看到哪些依赖在运行时被重新预构建。根据日志去调整 include/exclude，是最直接的优化路径。我通常会在项目初期就把这一步做好，避免后面遇到“某页面首次打开特别慢”的玄学问题。

5.2 解决开发服务器“变慢”的几个常见操作

Vite 开发态一旦跑起来，极少出现“越来越慢”的情况，如果你觉得慢，先检查三件事。第一，是不是每次启动都在重新预构建所有依赖？看看node_modules/.vite/deps目录是否被清掉过，或者 lockfile 是不是一直在变，导致缓存失效。第二，文件监听是不是把大目录也纳入进来了？通过server.watch.ignored把node_modules、.git、dist这些肯定不需要监听的大目录忽略掉，能大幅降低 CPU 和文件系统开销：

export default { server: { watch: { ignored: ['**/node_modules/**', '**/.git/**', '**/dist/**'] } } }

第三，源码编译链路是不是塞了太多自定义插件？有一些从 Vue CLI 时代迁移过来的项目，把 babel-loader、eslint 等步骤全塞进 Vite，结果每一步都拖慢速度。Vite 的快是建立在保留标准插件链路、减少额外处理上的，插件插得越多，越快这个优势就越弱。如果项目里存在大量页面，也建议配合动态 import 做路由懒加载，让开发服务器只关心当前路由的模块，而不是一上来就编译整个应用。

5.3 Vite 与微前端、Next.js 等方案并存时的性能取舍

热搜词里还有“vue3 + vite + 微前端方案”和“nextjs 和 vite”。微前端现在不少团队在用，用 Vite 做子应用或基座时，要注意几个点：Vite 子应用开发时用原生 ESM 加载，和其他框架的沙箱、依赖共享机制可能需要适配；各子应用最好有独立的预构建缓存目录，避免互相干扰；生产构建时，如果主应用用 qiankun 或 module federation，Vite 产物的 script 加载方式和 webpack 产物存在差异，遇到兼容问题要优先检查资源 base 路径、entry 配置这些细节。这些问题不属于“慢不慢”的范畴，但它会直接影响你是否能顺利把 Vite 落地到真实项目里。

至于 Next.js 和 Vite，其实定位不太一样：Next.js 是 React 全栈框架，集成了路由、SSR、数据获取等能力，构建工具早期基于 Webpack，后来也在引入 Turbopack；Vite 是完整的构建工具和开发服务器，本身不限定 React 还是 Vue。两者都能“很快”，但快的方式不一样：Vite 依赖原生 ESM 的按需加载，Next.js 则有一整套静态生成和服务端渲染的流程。选型时更要看项目需要的是框架能力还是高度定制的构建链，不要因为单一速度指标就冲动迁移。

5.4 让 Vite 的速度优势落到实际项目的最后一点建议

最后说一个我自己的实践心得。很多人问“Vite 为什么不快”，大部分时候不是 Vite 的问题，而是你还没有理解它的两种模式：开发态是“按需传输”，生产态是“完整打包”。在开发态，你要做的是减少预构建目标和额外插件，保持模块链路的简洁；在生产态，你要做的是合理分 chunk、控制 sourcemap 和静态资源大小。把这两套逻辑分开思考，你很少会再遇到“Vite 速度不行”的困惑。

我最近在一个人数规模不小的团队里推进 Vite 迁移，开发态启动稳定在一秒以内，冷启动不用再像以前那样等 Webpack 转圈。后面遇到的各种报错也确实都能按照“先看是不是模块兼容问题，再看是不是构建链路问题”的思路快速定位。Vite 的快，本质上来自它敢于改变开发模式，而不是把所有的兼容负担都往浏览器端塞。如果你在迁移过程里也遇到类似热搜词里的那些坑，先别急着骂 Vite，把开发态和生产态分开看，再回头审视自己项目里是不是塞了太多本不该由编译器承担的工作，答案往往就自己出来了。