Skip to content
webpack 与 Vite 概述
前端构建工具的起因
几年前，一个前端页面可能只需要三五个 <script> 标签就能跑起来。当应用的模块数量从十几个涨到几百个时，手写脚本标签、管理加载顺序、防止全局变量冲突会很快变得不可控。与此同时，项目开始使用 TypeScript、JSX、Sass 等非原生 JavaScript 或 CSS 的语法，浏览器无法直接解释，需要将它们转换成标准格式。于是就有了构建工具的核心问题：模块解析与合并、非标准语法的编译、静态资源的处理，以及网络请求数量和缓存策略的优化。
早期解决方案包括在线编译、AMD/CommonJS 的运行时加载器等，但这些方案要么对开发效率不够友好，要么在性能上存在不足。最终逐渐形成两类主流的做法：一类是先完整打包再加载的静态模块打包器，另一类是直接利用浏览器原生模块机制的开发服务器。webpack 和 Vite 分别是这两类思路的代表。
webpack：静态模块打包
依赖图与 bundle
webpack 把项目中所有资源都看作“模块”。不管是 JavaScript 文件、样式、图片还是字体，只要能通过相应的 loader 处理，就都能被纳入模块系统。从指定的入口文件开始，webpack 顺着 import／require 语句逐层找出所有依赖，构建出一张有向的依赖图，然后按照既定的分块策略把图中的模块输出为一个或多个 bundle 文件。
这个过程完全在构建阶段完成，浏览器拿到的是已经拼接、压缩、转换后的静态文件，不再需要处理模块之间的依赖关系。
示例：从入口模块到 bundle
一个最小的项目结构：
src/
index.js
math.js
package.jsonsrc/math.js
javascript
export function add(a, b) {
return a + b;
}src/index.js
javascript
import { add } from './math';
console.log(add(1, 2));package.json 中配置构建脚本（需安装 webpack 及 cli）：
json
{
"scripts": {
"build": "webpack --entry ./src/index.js --output-path dist"
},
"devDependencies": {
"webpack": "^5.88.0",
"webpack-cli": "^5.1.4"
}
}运行 npm run build，webpack 从 index.js 出发找到 math.js，将两个模块封装在一起，输出 dist/main.js。打开生成的 bundle 会看到 webpack 注入的模块引导代码：定义了一个模块映射的对象，并用一个加载函数依次执行每个模块。这层运行时机制负责维护作用域隔离和加载顺序，使得最终在浏览器里看起来像是所有代码都写在一个文件中。
在实际项目中，不只是处理 JavaScript。通过 loader，webpack 可以把任何文件类型转成模块。一个常见场景是在 JavaScript 中导入 CSS：
先安装 loader：
bash
npm install --save-dev style-loader css-loader然后在 webpack 配置中声明规则：
javascript
// webpack.config.js
module.exports = {
entry: './src/index.js',
output: { path: require('path').resolve(__dirname, 'dist') },
module: {
rules: [
{
test: /\.css$/,
use: ['style-loader', 'css-loader']
}
]
}
};这里 css-loader 负责解析 CSS 文件中的 @import 和 url() 语句，style-loader 则把解析后的 CSS 以 <style> 标签的形式注入到 DOM。两个 loader 从右到左依次执行：先经过 css-loader，再由 style-loader 处理。除了内联样式，也可以通过 MiniCssExtractPlugin 这个插件将 CSS 提取为独立文件，便于浏览器并行下载和缓存。
插件与 loader 的职责不同：loader 处理的是单个文件的转换，插件则作用于整个构建流程，包括 bundle 优化、HTML 模板注入、环境变量替换等任务。
Vite：基于原生 ESM 的开发服务器
开发模式：按需编译
Vite 在开发环境下不进行全量打包。启动 vite 命令时，它会在本地开启一个开发服务器，并直接提供基于原生 ES 模块（ESM）的源代码。浏览器通过 <script type="module" src="/src/main.js"> 发出第一个请求后，Vite 拦截这些请求，对需要编译的模块（例如 .vue、.tsx、.less）进行实时转换，然后将可执行的 ESM 返回给浏览器。浏览器收到代码后，会根据其中的 import 语句继续请求依赖模块——整个过程与项目中的模块数量几乎无关，冷启动速度取决于服务器启动时间和第一个模块的编译成本，而非项目总规模。
对于第三方依赖（node_modules 中的库），Vite 会用 esbuild 预先将它们打包成单个 ESM 模块并缓存。esbuild 由 Go 编写，速度远快于基于 JavaScript 的打包器，所以预构建阶段也不会成为瓶颈。
示例：浏览器直接加载 ESM
用 Vite 启动一个简单的原生 JavaScript 项目：
bash
npm create vite@latest demo -- --template vanilla
cd demo
npm install
npm run dev打开浏览器访问 http://localhost:5173，在开发者工具的网络面板中可以看到一系列 .js 文件的请求。以默认模板为例：
index.html— Vite 注入客户端脚本并处理模块入口。/src/main.js— Vite 直接返回源代码，其中import './style.css'会触发另一个 CSS 请求。/src/style.css— Vite 将其转换为一个可注入样式的小型 ES 模块。
如果修改 main.js 中的内容，浏览器只会重新请求该文件以及受影响的模块，整个页面不需要刷新，状态也不会丢失。这就是模块热替换（HMR）的效果。它的实现并不需要重新打包整个应用，而是通过 WebSocket 通知浏览器某个模块已失效，浏览器随即发起一次精确的重新请求。
正式构建
开发环境的这种“按需”机制只能在支持 ESM 的现代浏览器上运行。当需要将代码部署到服务器时，Vite 会转而使用 Rollup 进行打包。执行 vite build 后，所有源代码和依赖会被合并、压缩、代码拆分，产出适用于正式部署的静态资源。这一步的行为和传统打包器类似，但构建过程与开发体验解耦，开发者可以享受开发时的即时反馈，而不会因为构建方案限制最终产物的优化程度。
对比：速度、生态、配置、兼容性、场景
速度
冷启动：Vite 只需要启动服务器并进行轻量的预构建，启动时间通常保持在几百毫秒；webpack 需要从入口出发全量解析模块并打包，项目越大耗时越长，大型项目可能需要数分钟。
模块热替换：Vite 的 HMR 是基于 ESM 的精准失效通知，无论项目大小几乎瞬时完成；webpack 的热更新需要重新编译相关的 chunk，模块数量增多时能感受到明显延迟。
生态
webpack 拥有十几年的积累，loader 和 plugin 的数量庞大，几乎能找到适配任意文件类型和构建需求的方案。很多框架和工具（如 Next.js 早期版本、Angular CLI）直接内建于 webpack 之上。
Vite 自身提供了一套基于 Rollup 的插件接口，同时兼容一部分 Rollup 插件，官方和社区也提供了针对 Vue、React、Svelte 等框架的第一方支持。对于特定需求（如某种旧式模块格式的转换），可能暂时缺少现成插件，需要自行编写或等待生态成熟。
配置
webpack 的配置项涵盖入口、输出、loader、插件、解析规则、优化策略等，概念较多，写出一个兼顾开发和正式构建的配置文件可能需要半天以上的学习。这种复杂度也带来了极高的控制力：可以精确调整每一个构建细节。
Vite 的配置默认即支持 TypeScript、CSS 预处理器、静态资源导入等常见功能，多数情况下只需在 vite.config.js 中声明框架插件即可。对于深度定制场景，配置项虽然不如 webpack 丰富，但常用需求基本被覆盖。
兼容性
webpack 通过 loader 可以将 CommonJS、AMD、UMD 等任何模块格式转换为可执行的代码，并能生成兼容老旧浏览器的 ES5 bundle。任何能在 Node.js 中运行的模块，webpack 几乎都能打包。
Vite 的开发服务器强依赖浏览器对 ESM 的支持，不支持 IE 等旧浏览器。第三方依赖如果是 CommonJS 格式，会由 esbuild 在预构建阶段转换为 ESM，但如果依赖包含动态 require 或对 __dirname 等 Node 特性的复杂使用，可能在转换时遇到问题。正式构建阶段使用 Rollup，也要求所有模块最终都能转换为 ESM 或 Rollup 兼容的形式。
适用场景
- 新起步的中小型项目、Vue/React/Svelte 的单页应用、组件库的开发：Vite 适合，因为配置简单、开发反馈快。
- 大型历史项目、已深度依赖 webpack 定制构建流水线的项目、需要兼容低级浏览器的项目：webpack 更稳，团队熟悉度和插件完整性可以避免大量迁移成本。
- 快速原型或演示项目：Vite 极快的启动速度会让迭代更流畅。
- 多页应用、需要极端构建优化的场景：两种工具都可以胜任，但 webpack 的优化插件生态更完整。
初步选择方向
对于新项目，可以用一个粗略的判断逻辑：
- 项目团队成员是否已经深入掌握 webpack，并且尚未遇到明显的开发瓶颈？选择 webpack，避免额外的学习成本。
- 项目类型是否为库或需要组件按需加载的场景？Vite 的库模式封装了 Rollup，可以快速产出 ESM 和 CommonJS 两种格式。
- 是否需要兼容 IE11 或更低版本？只能选择 webpack。
- 依赖中是否包含大量无法转换为 ESM 的旧式模块？webpack 的兼容性更广。
- 是否重视开发时的冷启动和热更新即时性，并且浏览器环境支持原生 ESM？Vite 有明显优势。
没有哪个工具在所有维度上都是更优解，选型时要比较的是工具特征与项目当前及未来需求的匹配度，而不是纯粹的流行度。
注意点
- webpack 的配置复杂度是一把双刃剑。小型项目投入过多精力在构建配置上可能会掩盖业务开发的时间比例；大型项目则可能因为这种灵活性获得更精细的优化空间。
- Vite 的插件数量虽然增长很快，但仍然存在某些 webpack 强力插件（例如某些精细化分包分析工具）在 Vite 中缺乏等价实现的情况。迁移老项目前建议先排查这类依赖。
- 如果团队已经长期使用 webpack，开发体验也处于可接受的范围，不必因为工具热度而强行切换。工具迁移的成本往往比预期高，包括构建脚本、CI/CD 集成、团队培训等。
- Create React App (CRA) 已停止维护，React 官方文档现在推荐使用 Vite、Next.js 或 Remix 等方案。因此 React 新项目选用 Vite 是合理且官方认可的做法。
- 工具选择应与项目的生命周期、团队技术栈、维护周期挂钩，而不应仅仅因为某个工具的冷启动快几秒就做出决定。