vitejs/vite

解决什么问题

前端团队都熟悉这套流程：改一行代码，等打包器把越来越大的依赖图重新构建，刷新，再改。项目越大，等待越久；配置、插件、资源处理、旧浏览器兼容这些事本身也变成维护负担。Vite 把工作拆成两半：开发服务器基于原生 ES Module 按需转换浏览器真正请求的模块，生产构建则交给 Rolldown 打包。它的目标很明确——让开发循环变快，而不是堆功能清单。

有什么不同

Vite 的核心是架构选择：不预先打包整个应用再启动服务，而是依赖浏览器模块加载器做按需转换，所以冷启动和 HMR 不随应用规模线性变慢——这正是打包优先工具的老问题。和 webpack 相比（多数团队真正在做的对比），Vite 用约定优先的配置和更窄但更易上手的插件接口，换掉了 webpack 的深度可配置性和庞大 loader 生态。和“打包器开 watch 模式”相比，Vite 把开发与构建两条路径在概念上分开：同一份配置覆盖两者，但开发服务器不是被监视的打包器。默认不够用时，插件 API 和带类型的 JavaScript API 是扩展点。

适合谁

使用 Vite 所支持框架构建现代 SPA 和多页前端的团队收益最大，尤其是开发服务器启动和 HMR 延迟每天都能感受到的大型代码库。库作者也能用带类型的 JavaScript API 搭建自定义构建流程。依赖大量 webpack loader 链或资源图很特殊的团队，迁移前应逐一核对插件等价性——Vite 不是每份 webpack 配置的平替。需要兼容很老浏览器的项目，要提前规划 @vitejs/plugin-legacy，不能默认开箱即用。

上手成本

真正的成本在迁移，不在安装。替换现有 webpack/Rollup 配置意味着把 loader 重新映射为 Vite 插件、重新检查环境变量处理、重新验证生产产物。项目成熟、采用面广、MIT 许可、贡献者众多，风险主要在你的配置上而非工具稳定性。README 写得很薄，Node 版本支持、当前打包器行为等细节都在文档里，建议直接按官方安装与迁移指南操作，不要从 README 推断。

点评

Vite 是成熟项目而非短期爆红：8.3 万+ star，仓库始于 2020 年，如今在 TypeScript 月榜上仍能一个月新增数百 star。增长是稳态而非爆发式，这对基础设施类项目反而是好信号。新项目采用风险低，从 webpack 迁移则属于中等风险。今天启动前端项目，值得认真考虑；如果现有 webpack 配置稳定、开发速度也不痛，那迁移是可选项。