Vite 和 Webpack 选哪个，看项目阶段

2026-09-23 前端构建,构建工具选型,Vite,Webpack

我手上那个简笔画画板是纯前端项目，两天写完，用的就是 Vite。而 admin 那套已经跑起来的东西，只有关键页面才用了 Vite。Vite 和 Webpack 该选哪个，答案不在工具本身，在你项目处在哪个阶段。

新项目直接上 Vite，老项目别急着换。判断标准是「你的构建时间痛点在哪」，不是「哪个工具更新」。

一、Vite 和 Webpack 该选哪个，先看四个维度

我不比功能清单，只比真正会咬到你的四件事。

| 维度 | Vite | Webpack |

|------|------|---------|

| 开发启动 | 按需编译，文件多了也不会明显变慢 | 全量打包，工程越大启动越慢 |

| 生产构建 | 用 Rollup，配置少但可干预的钩子少 | 可干预的钩子多，深度定制空间大 |

| 生态与老插件 | 兼容主流方案，冷门加载器可能要换写法 | 存量插件最全，什么奇招都有 |

| 迁移成本 | 老项目要改配置、改后缀写法 | 已经在跑，不动就没有成本 |

这四行里，只有最后一行是多数人的真实约束。前两行决定新项目怎么选，最后一行决定老项目要不要动。

Vite 适合三类人：新起的前端项目、以 Cocos 之外的 Web 页面为主的独立项目、以及一个人维护的项目。

原因很直接。一个人维护的时候，最贵的是等待，本地改一行等很久才看到效果，注意力就断了。Vite 把这块成本压得很低。

Webpack 适合另外三类人：用了大量自定义 loader 的老工程、需要把构建流程塞进复杂分支的团队、以及构建产物被别的系统强依赖的项目。

这类项目里构建配置本身就是业务的一部分，换工具等于重写一遍构建逻辑，风险大于收益。

新项目我一律 Vite，老项目我一律不动。

这个选择不是技术偏好，是「改动边界」的考虑。新项目里构建配置不值钱，随便改；老项目里构建配置是踩过坑才长成现在这样的，每一条都有原因，可能连原作者都忘了。换工具省下的时间，很可能不够填迁移时炸出来的坑。

我现在真正常用的，是把两类项目分开：新东西新工具，老东西老工具，互不打扰。

如果你确实想迁，第一件事不是改配置，是先跑通一次生产构建。

开发环境能跑不代表生产能跑。很多老项目依赖的写法只在 Webpack 的特定环节成立，开发时被跳过了，生产构建才暴露。先在分支上完整跑一次打包和产物校验，再谈别的。

动作：把构建产物在真实环境里跑一遍，而不是只看构建有没有报错。构建成功和页面能用是两件事。

有人喜欢一个仓库只用一种工具，觉得这样才整齐。

我现在的看法是，整齐是给看代码的人爽的，不产生任何收益。两个工具并存是可接受的成本，迁移炸出来的坑是真实的成本。除非你有明确的理由，否则不要为了统一而迁移。

真要我给一个判断口径：如果迁移能让每天的等待时间明显下降，就值得做；如果只是看起来更现代，那就不值得。

Vite 和 Webpack 该选哪个，问的其实是「你现在最缺什么」——缺等待时间就选 Vite，缺稳定就跑着别动。

Q：Vite 和 Webpack 该选哪个，小项目也要考虑吗？

A：小项目直接选 Vite，不用纠结。构建耗时短的项目里，两者的差别本来就体现不出来，选配置少的那个更省事。

Q：老项目换成 Vite 值得吗？

A：多数情况下不值得，除非你的开发启动时间已经长到影响每天的工作节奏。先量一下启动耗时，再决定要不要动。

Q：两个工具能同时用在一个仓库里吗？

A：可以，老目录保持原样，新的子项目单独用另一套配置。这样迁移风险被限制在新目录里，代价是要维护两份配置。