脚手架入门：必要性、核心功能与执行原理

脚手架的定位与学习难点

简介：脚手架属于前端基础架构，是前端研发自动化的关键工具

• 为什么要学脚手架

  • 日常开发离不开脚手架
    • Vue CLI、Create React App 创建项目，webpack、Vite 等工具也都提供 CLI
  • 基础架构已成为前端的重要分支
    • 项目规模变大后需要专门的技术架构支撑，大厂的研发中台本质就是一种支持研发的模式
  • 提升研发效率的主要抓手就是脚手架
    • 大厂通常有专门的基础架构团队维护脚手架，并在其中植入权限校验，保证安全和规范
    • 研发中台的 GUI 创建项目，背后的能力仍由脚手架提供

• 脚手架在研发体系中的作用

  • 前端、后端、组件库等项目都通过脚手架的项目模板创建
  • 前端发布由脚手架完成，后端可用 Travis 等 CI/CD 方案
  • 前端发布环节多：Git 提交、打包构建、代码规范检查、上传静态资源服务器、模板发布到后端、静态资源映射到 CDN
    • 全部手动操作不是架构方案，必须用工具自动化

• 为什么难

  • Web 应用运行在浏览器，脚手架是直接运行在操作系统上的客户端
  • 知识面更广：Node.js、操作系统（环境变量、管理员 / root 账户）、HTTP、WebSocket 等
  • 逻辑复杂且高度抽象，第一次看不懂很正常，需要反复看、反复练

• 掌握实现原理的好处

  • 能定位故障：例如"命令不存在"、脚手架执行报错
  • 能自己开发脚手架，少踩坑

• 技术路线

  • 先用原生 Node.js 开发脚手架，走通搭建 → 开发 → 发布全流程
  • 再用 Lerna 搭建多 Package 脚手架框架
    • Lerna：多 Package（multi-package）管理工具，React、Babel 等项目都在用，能大幅减少项目管理工作量

• 学习方法

  • 架构三部曲：掌握原理 → 独立思考 → 总结反思
    • 架构不是空中楼阁，必须能落地；落地的前提是掌握所用技术的实现原理
  • 深度剖析优秀开源项目，由表及里、由浅入深
  • 视角切换：从开发视角切到架构视角，从全局思考问题
  • 优秀的程序员不仅能实现功能，更要读懂别人的代码和思路

前端研发脚手架核心功能

简介：一条 init 完成项目创建，一条 publish 完成 Git 操作到构建发布全流程

• 安装与命令

  全局安装脚手架

  my-cli init # 项目初始化
  my-cli publish # 项目发布
  my-cli init -h # 查看命令的配置参数npm install -g @my-cli/core # 全局安装脚手架

  全局安装脚手架

  my-cli init # 项目初始化
  my-cli publish # 项目发布
  my-cli init -h # 查看命令的配置参数my-cli init # 项目初始化

  全局安装脚手架

  my-cli init # 项目初始化
  my-cli publish # 项目发布
  my-cli init -h # 查看命令的配置参数my-cli publish # 项目发布

  全局安装脚手架

  my-cli init # 项目初始化
  my-cli publish # 项目发布
  my-cli init -h # 查看命令的配置参数my-cli init -h # 查看命令的配置参数

命令 / 参数	说明
init [options] [type]	项目初始化
publish [options]	项目发布
clean [options]	清空缓存文件
help [command]	查看命令帮助
-V, --version	查看版本号
--debug	打开调试模式

• init 项目创建流程

• 红色是模板选择（模板可在服务端动态增加），绿色是最终结果

• 项目模板的价值

  • 比 Vue CLI 默认模板更精简，删除无关的演示内容
  • 内置 reset.css，也可以加入网络请求、接口定义等业务通用代码

• publish 发布流程

• 红色是云构建（脚手架通过 WebSocket 与远程服务器交互），绿色是最终产出的线上链接

• 关键点

  • 代码托管支持 Gitee、GitHub，仓库不存在时自动创建
  • 多人协作时都指向同一个开发分支，自动合并远程分支和 master，是一套标准的 GitFlow 流程
  • 首次发布约 83 秒，再次发布约 45 秒；手动操作通常要 10~20 分钟

• 测试发布 vs 正式发布

维度	测试发布 publish	正式发布 publish --prod
分支	保留开发分支 dev/x.y.z	删除开发分支
tag	不创建	创建 release tag 并同步到远程
访问	测试环境链接，如 https://dev.example.com/...	正式链接，同步到 CDN
再次发布	链接不变，刷新即可看到更新	要求升级版本号（大 / 中 / 小版本）

• publish 常用参数

参数	说明
--prod	正式发布
--refreshToken / --refreshOwner / --refreshServer	强制更新 Git token / owner / 平台信息
--force	强制更新所有缓存信息
--keepCache	保留缓存
--buildCmd <cmd>	手动指定 build 命令
--sshUser / --sshIp / --sshPath	模板服务器的用户名 / IP / 上传路径

开发脚手架的必要性

简介：站在架构师视角，先回答"开发它能带来什么价值"，核心目标是提升前端研发效能

• 大厂研发架构
  • 集团 → BU（Business Unit，业务单元 / 事业部）→ 业务线 → 前端团队
  • 不同团队开发 PC、H5、小程序等不同项目，但有三类共通操作

• 红色是三类共通操作，下面是每类包含的具体工作

• 这些操作人工做既耗时又容易出错，脚手架把它们全部固化下来

• 脚手架核心价值

价值	说明
自动化	重复代码拷贝、Git 操作、发布上线自动完成
标准化	项目创建、GitFlow、发布和回滚流程统一，按提示操作即可，不用记规范
数据化	研发过程系统化、可量化，可统计创建项目、Git 操作、构建发布各自耗时

• 数据化最重要：所有努力都是为了持续改进研发流程，量化后才能知道优化幅度

• 和自动化构建工具（Jenkins、Travis）的区别

维度	Jenkins / Travis	前端研发脚手架
触发和执行位置	Git hooks 触发，在服务端执行	在研发人员本地执行
覆盖范围	只能覆盖云构建部分	还能覆盖本地创建项目、本地 Git 操作
定制方式	开发插件，过程复杂，使用 Java	用 Node.js 开发，前端更熟悉

• 结论
  • 有了自动化构建工具，仍然需要自研前端研发脚手架
  • 前端构建流程相对简单（安装依赖、构建、上传资源），自研成本低、节省时间多、后期可控
  • 也有大厂把云构建接入 Jenkins，但构建过程如何在脚手架中展示仍需定制
  • 团队后期沉淀的大量组件也需要工具管理，同样属于脚手架的范畴

从使用角度理解什么是脚手架

简介：脚手架本质是操作系统的客户端，通过命令行执行

• 命令组成

  #vue create vue-test-app --force -r https://registry.npm.taobao.orgvue create vue-test-app --force -r https://registry.npm.taobao.org

部分	示例	说明
主命令	vue	脚手架本身
command	create	子命令，向脚手架请求完成一个动作
command 的 param	vue-test-app	子命令的参数，这里是项目名
option	--force	选项，相当于配置；目录已有文件时强制覆盖，不加则中断执行
option	-r	简写形式，等同于 --registry，指定安装依赖的源
option 的 param	https://registry...	选项的参数

• 关键点

  • --force 可理解为 --force true，简写为 -f
  • 一条横线 - 是简写，两条横线 -- 是全称
  • vue create --help 可以查看所有 option

• 执行原理

• 红色是理解原理的关键：命令只是软链接，最终由 node 执行一个 JS 文件

• 查看命令在环境变量中的位置

  /Users/xxx/.nvm/versions/node/v12.11.1/bin/vuewhich vue

  /Users/xxx/.nvm/versions/node/v12.11.1/bin/vue# /Users/xxx/.nvm/versions/node/v12.11.1/bin/vue

• node 安装目录结构（重点关注 bin 和 lib）

  node 安装目录
  ├── bin/
  │ └── vue -> ../lib/node_modules/@vue/cli/bin/vue.js # 软链接（ls -l 显示 l 开头）
  └── lib/
  └── node_modules/ # 全局依赖，npm install -g 安装到这里
  └── @vue/cli/
  ├── bin/vue.js # 实际执行的入口文件
  └── package.json

• 从应用角度看如何开发一个脚手架

• 红色是最关键的一步，绿色是最终效果
• 待解决的三个问题
  • 为什么全局安装 @vue/cli 后，会自动在 bin 目录添加 vue 软链接
  • 全局安装 @vue/cli 时到底发生了什么
  • vue 指向的是 JS 文件，为什么不用输入 node vue.js 就能直接执行

面试/考试记忆点

• 脚手架本质是操作系统的客户端，通过命令行执行
• 脚手架命令由主命令、command、command 的 param、option、option 的 param 组成
• 执行原理：终端在环境变量中找到命令 → 命令是指向全局 node_modules 中 JS 文件的软链接 → node 执行该文件 → 解析参数并执行对应 command
• 全局安装的包在 node 安装目录的 lib/node_modules，可执行命令在 bin 目录
• 开发前端研发脚手架的核心目标是提升前端研发效能
• 脚手架三大核心价值：自动化、标准化、数据化
• 大厂前端共通操作三类：创建项目 + 通用代码、Git 操作、构建 + 发布上线
• Jenkins、Travis 在服务端执行，覆盖不到本地创建项目和本地 Git 操作，且定制要用 Java，所以仍需自研脚手架
• 研发中台的 GUI 背后能力仍由脚手架提供
• 架构三部曲：掌握原理 → 独立思考 → 总结反思