外包接单三年，我的构建工具选型思路全变了

上周五深夜，我远程帮客户改前端工程配置。那项目同时混用 Vite、Webpack 和 Gulp，改完跑通的那一刻，我想聊聊构建工具这件事。

接外包这几年，什么项目都见过：CRA 起步两年没升级，node_modules 比源码大十倍；传统企业用 Maven 打包前端资源，路径写死。每次接手，我先看 package.json 里的 scripts 和构建配置。构建工具选得对不对，直接决定后续开发是享受还是受刑。

我的选型变化：2024 年前基本无脑 Webpack，觉得生态全。后来接了个 AI 应用外包，前端要处理大量实时渲染数据流，Webpack 冷启动十几秒让人想砸键盘。当时 Vite 5 刚出，迁移后启动从 14 秒降到 400 毫秒，回不去了。

那阵子 AI 应用火，客户常拿 Stable Diffusion 生成的界面图说“照这个做”，但 UI 细节全得手动调。更离谱的是有客户用 Manus 自动生成整套脚手架，构建配置里同时装了 esbuild、rollup 和 webpack，依赖冲突刷满屏。我花了一下午才理顺，心想：AI 再火，构建工具这层地基还得人来把稳。

现在我的选型思路很简单：新项目默认 Vite，老项目能迁就迁，迁不动就保持 Webpack 别乱动。工具链越简单越好，别搞“多构建器并行”。我见过有人为追求极致性能，不同模块用不同构建器处理，结果 CI 产物路径全乱，线上白屏两小时。这种技术债，客户不会为你的“架构优雅”买单。

构建配置一定要写注释。我接过的二手项目里，十个有八个的 vite.config.ts 或 webpack.config.js 是裸奔的，一堆魔法数字和正则，原作者回来看都得愣三秒。我现在每个 plugin 为什么加、每个 alias 指向哪里、环境变量用途，全部写清楚。可维护性在外包项目里尤其重要，因为你永远不知道下一个接手的人是不是凌晨三点被客户电话吵醒的倒霉蛋。

构建工具够用就行，别追新。Vite 6 出新特性就连夜升级，结果某个 loader 不兼容，回滚都麻烦。我的原则：大版本出来先观望两个月，等社区把坑填得差不多再动。

构建工具说到底是个工具，不是信仰。把时间花在业务上，比折腾构建器划算得多。