Webpack vs Vite：为什么Vite快得飞起

Webpack和Vite解决同样的问题——把源码变成浏览器能跑的东西——但dev模式走了相反的路。Webpack的dev server要打包。启动时建完整依赖图，每个文件跑一遍所有loader（babel-loader、ts-loader、css-loader等），产出一个bundle，再serve。中等规模应用冷启动10-30秒。每次保存文件，HMR从改动模块沿着图走，重新生成受影响的chunk。Vite走了完全不同的思路。dev模式下Vite根本不打包，直接以原生ES模块形式通过HTTP把源文件发给浏览器。浏览器加载index.html时看到import语句，为每个模块发独立HTTP请求；Vite现场转换每个请求（TS→JS、JSX→JS、CSS→JS import），用的是esbuild，比Babel快一两个数量级。第三方依赖——React、lodash等——用esbuild预打包成每个依赖一个ESM文件，因为node_modules里一个包可能有几百个小文件，让浏览器一个个请求太慢。所以Vite的dev冷启动近乎瞬时——什么都没提前打包。HMR也瞬时——改动只需重新转换单个文件，不走任何图。为什么Webpack不照做？浏览器原生ESM最近才实用化，Webpack的架构是围绕打包设计的。生产环境Vite反而会打包——用Rollup产出传统chunked bundle，因为真实用户访问不能每页几百个HTTP请求。所以Vite是"dev ESM，prod Rollup"两个模式。选型：2026年新项目默认Vite。Webpack继续适合：巨型遗留代码迁移代价超过收益的、复杂自定义loader链或Module Federation等Webpack工具链更深的场景。Rspack是Rust重写的Webpack兼容版，想要Vite速度又不想重写Webpack配置的团队选它。