Vite vs Webpack核心差异与ESBuild原理
对比Vite和Webpack在开发模式和生产模式下的核心差异，解释Vite为何比Webpack在开发时快10-100倍，以及ESBuild在其中扮演的角色。Vite使用Rollup进行生产构建的原因是什么？
回答
古法程序员
核心差异
| 维度 | Vite | Webpack |
|---|---|---|
| 开发模式 | 原生ESM（无打包） | 全量打包（Bundle） |
| 冷启动 | 秒级（按需编译） | 10-30秒（全量编译） |
| HMR速度 | 模块级（单文件更新） | chunk级（需重新打包） |
| 构建工具 | Rollup | Webpack |
| 预构建 | ESBuild（Go编写） | 无 |
为什么Vite开发时快？
1. 原生ESM按需加载
- 浏览器直接请求
.vue/.tsx等文件，Vite实时转译并返回ESM - 浏览器只加载当前页面需要的模块，而非整个应用
import { debounce } from './utils'只请求utils模块和相关依赖
2. ESBuild预构建
// vite.config.js
export default defineConfig({
optimizeDeps: {
include: ['lodash-es', 'react']
}
});
- 将CommonJS/UMD依赖转为ESM
- 将数百个依赖模块合并为少量chunk（减少请求数）
- ESBuild使用Go语言编写，比JS编写的打包器快10-100倍
3. 按需编译（ESBuild）
- 只有被浏览器请求的模块才被编译
- Webpack需要预先编译整个应用依赖图
ESBuild原理
- 语言：Go，充分利用多核CPU和并行处理
- 解析：手写解析器（非递归下降），一次遍历完成词法/语法分析
- 输出：原生支持ESM/CJS/IIFE转换
- 局限：不支持TypeScript类型检查（仅去除类型注解）
生产构建使用Rollup的原因
- Tree Shaking更成熟：Rollup的ESM静态分析更彻底
- 代码分割更精细：Rollup对动态import的分割优化更好
- 插件生态：Rollup插件体系成熟稳定
- ESBuild问题：生产环境下Tree Shaking不够彻底，CSS处理能力弱
Vite的最佳实践：
- 开发用ESBuild加速，生产用Rollup优化
- 对于大库（antd/element-plus），开启
optimizeDeps预构建 - 配置
build.rollupOptions自定义生产构建