Sunqy 文档库

主题

27 · 主流脚手架与工程化平台对比 ​

本篇解决什么问题： 自研 CLI 有成本，现成工具也各有脾气。本篇横向对比主流方案， 并给出自研 vs 二开 vs 直接用的判断框架——多数团队不该自研。

📌 与 A26 的分工：A26 讲怎么自研，本篇讲什么时候别自研。

开篇速览 ​

工具定位状态
CRA（create-react-app）React 官方脚手架⚠️ 已不推荐（官方转向 Next/Vite）
Vue CLIVue2 时代官方脚手架⚠️ 维护模式（新项目用 create-vue）
create-vueVue3 官方脚手架✅ 推荐
Vite create（npm create vite@latest）多框架通用✅ 推荐（快、简洁）
Next.js / Nuxt框架 + 脚手架一体（含 SSR）✅ 需要 SSR/SSG 时
Nx / TurborepoMonorepo 工程化平台✅ 多包仓库
Yeoman老牌 generator 生态⚠️ 逐渐边缘
Plop项目内代码生成✅ 与脚手架互补

一、逐个拆 ​

1.1 Vite create（当前默认选择） ​

bash
npm create vite@latest my-app -- --template vue-ts
✅ 优点❌ 缺点
极快（原生 ESM，无打包）只给最小骨架，规范（lint/test）要自己加
模板覆盖主流框架不含团队规范，多人协作要二次封装
配置透明、易改造—

适合：小项目、个人项目、作为自研脚手架的底座。

1.2 create-vue（Vue3 官方） ​

bash
npm create vue@latest

交互式勾选 TS / JSX / Router / Pinia / Vitest / ESLint / Prettier，开箱即完整。 比 Vite create 给得多（含 Router、Pinia、测试），适合正经 Vue 项目。

1.3 CRA 的现状 ​

⚠️ CRA 已进入维护状态。React 官方文档现在推荐 Next.js 或 Vite 起步。 原因：CRA 基于 Webpack，启动与热更新慢，且不支持 SSR。

新项目不要再用 CRA；老项目可考虑迁移到 Vite（迁移成本主要在自定义 Webpack 配置上）。

1.4 Next.js / Nuxt：框架而非单纯脚手架 ​

它们自带路由、渲染模式、数据加载，脚手架只是附赠。

选它的理由不选的理由
需要 SSR / SSG / ISR（见 A13）纯后台系统用不上，反而增加约束
想要 约定式路由 + 文件路由需要完全掌控配置
需要 SEO学习成本与心智负担更高

1.5 Nx / Turborepo：Monorepo 平台 ​

不是脚手架，是"多包仓库的构建与任务编排平台"，但也带 generator。

bash
npx create-nx-workspace@latest
nx g @nx/react:component Button    # 生成组件
nx affected:test                    # ✅ 只测试**受影响**的包
能力说明
任务编排依赖拓扑排序，并行执行
缓存本地 + 远程缓存，二次构建秒级
affected只跑改动影响到的包（大仓库刚需）
generator生成 app / lib / component，规范统一

选型：单包项目不需要 Nx。多包（≥3 个 package）且需要增量构建时再上。 轻量 Monorepo 也可以用 pnpm workspace + Turborepo（更简单）。

1.6 Plop：项目内的"小脚手架" ​

与上面都不同——Plop 在已有项目里生成文件（组件、页面、store 模块）：

js
// plopfile.js
module.exports = plop => {
  plop.setGenerator('component', {
    description: '创建一个 React 组件',
    prompts: [{ type: 'input', name: 'name', message: '组件名' }],
    actions: [
      { type: 'add', path: 'src/components/{{pascalCase name}}/index.tsx', templateFile: 'plop-templates/component.hbs' },
      { type: 'add', path: 'src/components/{{pascalCase name}}/{{pascalCase name}}.test.tsx', templateFile: 'plop-templates/component.test.hbs' },
    ],
  })
}

✅ Plop 与脚手架互补：脚手架管"项目诞生一次"，Plop 管"项目内无数次"。 详见 A28 · 代码生成与规范化工具链。

二、生成式 vs 配置式：两种设计哲学 ​

生成式（Generate）配置式（Configure）
做法把代码拷到你项目里通过插件/配置注入能力，代码在依赖里
代表Vite create、CRA eject 后、PlopVue CLI 插件、Next.js、Nuxt modules
优点完全可控，想怎么改怎么改易升级，改配置即可，无需动业务代码
缺点升级困难（改过就和上游分叉了）定制受限，黑盒感强

判断：

场景选
团队规范强、要长期演进、希望可升级配置式（封装成插件/preset）
需要完全掌控、一次性项目生成式
折中生成式 + 尽量少改（把定制放在插件里）

📌 Vue CLI 从"生成式"转向"插件化"（配置式），正是为了解决升级难的问题。

三、自研 vs 二开 vs 直接用：判断框架 ​

先问三个问题：

问题 1：需要"团队规范"落地吗？ ​

  • ❌ 不需要（个人/小项目）→ 直接用 Vite create / create-vue，别自研
  • ✅ 需要 → 问题 2

问题 2：有几个项目？规范变化频繁吗？ ​

项目数建议
1~2 个直接复制 + 手动维护，别自研
3~10 个封装 preset / Plop 生成器，或基于 Vite create 做薄封装
10+ 个、多团队自研 CLI（或 Nx workspace + 自定义 generator）

问题 3：自研的持续维护成本能承担吗？ ​

自研 CLI 的隐性成本（很多人低估）：

成本说明
模板要跟着生态演进Vite 4→5、Vue 3.3→3.4，模板不更新就落后
依赖升级与兼容inquirer/commander 大版本升级是破坏性的
答疑与支持同事用不了会来问你
文档没有文档的脚手架等于没有

🎯 结论（经验法则）： 能用 npm create vite + Plop + 一份规范文档解决，就不要自研 CLI。 自研的正确时机是：项目数量与规范复杂度让"复制粘贴"已经明显失控。

四、决策速查表 ​

场景推荐方案
个人/小项目起步npm create vite@latest
正经 Vue3 项目npm create vue@latest
需要 SSR/SSG/SEONext.js / Nuxt
后台管理系统Vite + 模板，别上 SSR
多包仓库（≥3 包）pnpm workspace + Turborepo；超大仓库用 Nx
团队有 10+ 项目要统一规范自研 CLI（见 A26）或 Nx generator
项目内重复造文件（组件/页面）Plop（见 A28）

自检清单 ​

  • [ ] 能说清 Vite create / create-vue / Next / Nx 各自的定位与适用场景
  • [ ] 知道 CRA 已不推荐及原因
  • [ ] 能区分生成式与配置式的取舍
  • [ ] 能按"项目数 + 规范复杂度 + 维护能力"给出 自研/二开/直接用 的建议
  • [ ] 能说出 Plop 与脚手架的互补关系

常见误区 ​

❌ 误区✅ 事实
"新 React 项目用 CRA"CRA 已进入维护状态，官方推荐 Vite / Next
"自研脚手架显得专业"维护成本常被低估；能不造就不造
"Nx 是所有项目的标配"单包项目用 Nx 是过度设计
"生成一次就完事了"模板必须持续演进，否则半年后就是技术债

动手练习 ​

  1. 用 npm create vite@latest 和 npm create vue@latest 各建一个项目，对比默认给你了什么（lint/test/router/store）。
  2. 用 pnpm workspace 搭一个两包的 Monorepo，加 Turborepo 跑一次 turbo run build，观察缓存效果。
  3. 给现有项目加 Plop，把"新建组件（含测试文件）"做成一条命令。

相关文档 ​