观点：前端工程化是否已经过度设计？聊聊我的看法

前端工程化走到今天，从“脚手架搭建”到“微前端治理”，从“Webpack 调优”到“Rust 工具链替换”，工具链越来越重，配置越来越深，抽象越来越多。身边不少老同事私下感慨：以前一个 `index.html` 加两个 JS 文件就能跑业务，现在初始化一个项目要装上百个依赖，跑起来之前先得花半天时间搞定 ESLint、Prettier、Husky、Commitlint、CI 流水线。于是问题来了：前端工程化，是不是已经过度设计了？

工程化解决了真问题，但也制造了新问题

不可否认，前端工程化最初的动机很纯粹：解决多人协作、代码规范、构建压缩、环境差异、模块复用等真实痛点。没有模块化和打包工具，大型应用很难维护；没有 lint 和自动化测试，代码质量全靠自觉，上线全靠烧香。工程化让前端从“页面仔”走向了“软件工程”，这是历史性的进步。

但今天的现状是，工程化的“军备竞赛”已经远远超出了解决痛点的范畴。很多团队用的工具链复杂度，甚至超过了业务逻辑本身。一个简单的管理后台，也要上 pnpm workspace、Monorepo、Turborepo、Changesets、Storybook、Vitest、Playwright……每一样单看都合理，合在一起就成了沉重的枷锁。开发者的精力被大量消耗在工具配置、版本升级、依赖冲突上，真正写业务代码的时间反而被压缩。

更典型的是“为了工程化而工程化”的倾向：项目还没有五个页面，就先把多层目录结构、接口请求封装、状态管理库、路由守卫、权限指令全部铺好；业务没有变化，就预先抽象出可复用的“组件库”和“工具包”；需求还没清晰，就引入设计系统、低代码协议、领域模型。这些设计在设想中很美好，但实际执行时往往流于形式——代码里充满没人调用的抽象，文件夹里躺着无人问津的公共模块。

过度设计的本质：用复杂度掩盖不确定性

我观察到的核心矛盾是：工程化本身是解决“不确定性”的手段，但当手段过度膨胀时，反而引入新的不确定性。

拿构建工具举例。过去我们问“Webpack 怎么配”，现在问“Webpack、Vite、Turbopack 怎么选”。每一次工具升级，本质上是想降低构建复杂度，可是升级本身又带来兼容性问题、插件生态迁移成本、开发环境的未知 bug。很多团队为了“更先进”而频繁切换工具链，结果真正被优化掉的不是开发者的等待时间,而是写代码的心情。

再看代码生成和约定式规范。很多团队制定了详细到每一行分号、每一个文件名大小写的规则，并辅以自动修复工具。这当然是好事，但如果规范叠加过度,反而束缚了表达。开发者每写一行代码都要考虑是否通过“统一规则”，而不是思考这个功能的本质。更可怕的是，一些通过代码生成器创建的项目，模板里塞满了太多无关的依赖和注释，真正想动手改一个按钮样式，得先绕过五层封装。

工程化设计还有一个隐藏的动机：防御性职业焦虑。当技术栈里堆满了新名词，职级评审的 PPT 就会显得饱满。这种“设计给简历看”的心理，让工程化的粒度越来越细，抽象层次越来越深。可产品不关心你用了多新的构建工具，用户也不在乎你的代码是否符合 DDD 分层架构。过度工程化最容易吞噬的，恰恰是对业务和体验的关注。

适度的工程化，是解决问题而不是展示能力

我并不是反对工程化，而是反对失去权衡的“堆料式”工程化。真正合适的工程化，应该遵循“需要时才引入”的原则，而非“别人有我也要有”。

一个小团队做活动页，完全可以不引入框架，或只用最简的构建工具。如果只有一个前端维护，就不必强行拆分 Monorepo；如果测试覆盖率一直不达标，就不必非得搭建一套完整的 QA 流水线。技术选型要看团队规模、项目阶段和业务复杂度。工程化的成本是看得到的（时间、学习、维护），收益却往往是长期的、间接的。如果短期内成本已经把团队压垮，那就谈不上长期的收益。

合理的工程化设计应该允许“人在回路”：配置要能看懂，抽象要能追踪，工具要能降级。比如用相对朴素的 CRA 或 Vite 模板启动，等到构建时间真的超过可接受范围，再引入缓存和拆分；等到多人协作频繁踩坑，再补上统一的 lint 与规范；等到跨仓库共享代码真的带来负担，再考虑 Monorepo。所有工程化动作都应当指向具体的、可量化的痛点，而不是为了向别人证明“我很专业”。

我自己经历过的教训是：一个内部后台项目，起初用最简单的 create-react-app 配置，后来为了“统一规范”迁移到自研脚手架，结果光改造路由和状态管理就花了两周。上线后并没有感受到开发效率的提升，反而因为脚手架封装太深，遇到一个小问题就无法在社区搜索到答案，只能自己翻 node_modules 里的源码。那次之后我深刻意识到：工程化的终极目标，是让代码的复杂度匹配业务的复杂度，而不是让工具链的复杂度淹没业务的复杂度。

回到“人”的视角

前端工程化的初衷，是让前端开发者从琐碎中解放出来，专注于创造用户体验价值。如果我们把更多精力花在解决工程问题本身，而忘了用户在浏览器里打开页面到底快不快、顺不顺，这本身就是方向上的失焦。技术永远为业务服务，工程化也不例外。过度设计的标志之一，就是团队开始讨论“要不要把 npm 换为 pnpm”时，却没人能说清楚这样做能给最终用户带来什么可感知的收益。

我的态度是：工程化不是越重越好，也不是越轻越好。它是一组权衡的结果。对于中小型团队和复杂业务不断演进的系统，建立轻量但可扩展的工程化基线，随痛点的出现逐步增加复杂度，才是更理性的路径。保持工具链“随时可以看懂并改掉”的能力，比堆叠最新奇的设计模式重要得多。前端工程化永远只是手段，而好的产品、顺畅的协作、可持续的增长才是目的。别让手段绑架了目的，共勉。