Webpack 和 Vite 有什么区别？为什么 Vite 启动更快？

简化版

Webpack 以模块依赖图和 bundle 为核心，开发启动通常先完成一轮依赖图构建；Vite 经典开发模式利用浏览器原生 ESM 按请求转换源码，并预处理较稳定的依赖，因此无需先打完整应用包，冷启动和局部 HMR 通常更快。当前 Vite 8 已采用 Rolldown 与 Oxc 工具链，生产构建不应再回答“默认使用 Rollup”。

详细版

Webpack 从入口递归处理 JS、CSS、资源等模块，loader 负责转换，plugin 介入编译生命周期，dev server 基于内存构建结果提供 HMR。持久化缓存、增量编译和合理 loader 范围能显著改善性能。

Vite 经典 dev server 启动时先提供服务，浏览器请求哪个源码模块就转换哪个；依赖因模块多、格式复杂且变化少，会被预处理并缓存。HMR 以模块边界传播，不必重建整个 bundle。

Vite 仍需处理解析、插件、框架转换和大量模块请求，大型项目并非永远零等待。Vite 8 用 Rolldown/Oxc 统一并加速工具链，官方也继续探索 full bundle mode；选型应基于真实项目插件兼容、构建结果和迁移成本。

完整版教学

一、两者首先是不同架构取舍

Webpack 把各种资源纳入统一模块图，通过构建得到 bundle，再由开发服务器交付。它的统一管线带来很强的定制能力，但初次可用前通常要完成较多前置工作。

Vite 的经典开发模式利用现代浏览器 ESM：先快速启动服务器，源码在浏览器请求时才解析、转换和返回。工作不是消失了，而是从“启动前全做”改成“按访问路径逐步做”。

记忆钩子：Webpack 经典模式偏“先准备再服务”，Vite 经典模式偏“先服务、请求到哪处理到哪”。

二、Webpack 怎样从入口得到页面资源

Webpack 从 entry 解析静态和动态依赖，loader 把非原生模块转换成 JavaScript 或资产模块，plugin 在解析、生成、优化和输出等阶段扩展行为。

entry → resolve → loader transform → module graph
                              ↓
                    chunk optimize → emit

这种模型让 CSS、图片、WebAssembly 和自定义格式都可进入同一依赖体系。代价是配置和插件间交互可能复杂，项目越大，首次图构建和无效转换越需要缓存与范围控制。

Webpack 不能简单等同于“每次全量重打”。它支持 watch、增量编译、HMR 与持久化缓存；一个配置良好的 Webpack 项目可能比配置失当的 Vite 项目更适合实际团队。

三、Vite 的经典开发服务器为什么启动快

浏览器直接请求入口 ESM，遇到后续 import 再发请求，Vite 只转换被请求的源文件。因此项目有 10,000 个模块而首页路径只触达 800 个时，启动阶段不必先处理全部 10,000 个。

浏览器 /src/main.ts ──> Vite 转换 main
          │ import
          ├─> /src/App.vue ──> 按需转换
          └─> /node_modules/.vite/deps/react.js

这并不保证首次页面打开与模块数无关。浏览器仍要发现和请求模块，插件转换也有成本；极大模块图、网络代理或重型框架插件会使首屏刷新变慢。

四、依赖预处理与 HMR 分别解决什么

第三方依赖可能包含大量内部模块或 CommonJS 格式。预处理把它们转换成浏览器易消费的 ESM，并合并过碎依赖，减少请求；依赖内容稳定，还可基于 lockfile 和配置缓存。

源码经常变化，不适合每次整体预打包。HMR 更新时沿模块接受边界传播，只让受影响模块失效；若边界无法接受更新，才可能扩大到父模块甚至整页刷新。

假设传统冷启动处理 8,000 个模块每个平均 0.4 ms，仅模块处理理论上约 3.2 秒；按需首路径处理 900 个约 0.36 秒。该算例只解释数量级，真实耗时还包含解析并发、插件、磁盘与缓存。

五、生产构建与版本边界必须说准确

生产环境直接发送成百上千个细碎源码模块会增加请求发现和优化难度，所以 Vite 仍执行打包、Tree Shaking、代码分割和压缩。不能把“开发时不预先打完整包”说成“Vite 永远不打包”。

版本背景	主要工具链表述
Vite 7 及更早经典版本	dev 常用 esbuild，生产常用 Rollup
Vite 8 当前版本	Rolldown + Oxc，生产由 Rolldown 打包

Vite 8 仍保留对 Rollup 风格插件 API 的兼容思路，但这不等于底层仍是 Rollup。面试遇到版本敏感题，先说明版本再比较，避免把历史正确答案当作当前事实。

六、怎样做真实选型和迁移评估

Webpack 生态成熟，历史 loader/plugin、Module Federation 和高度定制链路可能已经稳定运行；Vite 默认体验轻快，适合现代 ESM 项目和主流框架。选型不是比较官网口号，而是验证项目所需能力。

维度	要测量或核查的证据
开发体验	冷启动、首次页面、HMR P50/P95
生产结果	构建时间、体积、chunk、兼容目标
生态	必需插件、SSR、测试与框架集成
迁移风险	环境变量、资源路径、CommonJS、插件语义

迁移 PoC 应选择依赖最复杂的代表页面，而非只有首页的演示项目。还要比较 source map、CSS 顺序、动态导入错误和旧浏览器目标，确保“启动更快”没有换来生产回归。

如果 Webpack 冷启动 45 秒、Vite PoC 为 6 秒，改善约 86.7%；但迁移需要 8 人周且生产包反而增大 20%，仍需结合团队时间和用户收益决策。工程选型最终是总成本问题。

七、常见误区与追问

误区：Vite 完全不打包。 经典开发阶段按需服务 ESM，生产仍需要优化打包；当前 Vite 8 使用 Rolldown。
误区：Vite 当前生产构建默认使用 Rollup。 这是旧版本答案，Vite 8 已迁移到 Rolldown/Oxc 工具链。
误区：Webpack 每次修改都只能全量重新打包。 它支持增量编译、HMR 和持久化缓存，效果取决于配置。
追问：Vite 为什么要预处理依赖？ 为了处理 CommonJS/ESM 兼容、合并过碎模块并缓存稳定依赖。
追问：Vite 项目很大后为什么也可能变慢？ 按需模块请求、插件转换和浏览器发现链仍会累积成本。
追问：loader 与 plugin 有什么区别？ loader 面向模块内容转换，plugin 通过构建钩子扩展整个编译流程。
追问：怎样证明迁移值得？ 用代表性项目比较开发 P95、生产构建、产物质量、插件兼容与迁移维护成本。

八、加强记忆

把区别串成“开发调度、转换生态、生产版本、真实证据”：Webpack 经典架构先建图并产出 bundle，Vite 经典 dev 借原生 ESM 把源码处理延后到请求时；两者都有缓存、HMR 和生产优化。回答当前版本时必须补充 Vite 8 的 Rolldown/Oxc 迁移，选型则用代表性 PoC 和总成本收尾。

简化版

详细版