介绍workflows
代码托管平台 Github 我们应该比较熟悉。每次我们提交代码到 GitHub 仓库时，特别是开源项目，一般都会自动触发测试脚本运行，帮你验证代码没有引入新的错误。
这个其实就是 GitHub Actions ，一般我们把 YAML 脚本定义在 .github/workflows目录下。
一. 什么是 GitHub Actions 自动 CI 测试？
GitHub Actions 是 GitHub 官方提供的一套自动化工作流服务，可以用来自动化代码构建、测试、部署等流程。CI（持续集成，Continuous Integration）测试 是指在代码每次提交或者合并请求时，自动运行项目的测试代码，保证代码的正确性和稳定性。
那为什么要用 GitHub Actions 自动 CI 测试？原因也很简单：
自动化：减少人工手动测试的工作，省时省力。
快速反馈：提交代码后马上知道测试结果，发现问题及时修复。
保障质量：避免有问题的代码被合并进主分支，提升代码质量。
多平台支持：可以在不同操作系统和环境下自动测试，比如 Windows、Linux、macOS。
免费且无缝集成：直接集成在 GitHub 仓库，无需额外配置第三方服务。
常见的 CI 测试比如：Node.js 项目跑 npm test、Python 项目跑 pytest、Java 项目跑 mvn test,还有Docker 镜像构建和测试等等。
讲解workflows
.github/workflows 是 GitHub 强制约定的固定文件夹 ，专门存放 GitHub Actions 的自动化配置文件 ；每一个 .yml 文件 = 一个独立 Workflow（工作流） ，用来定义：在什么时机、在哪台机器、自动跑哪些任务。
下面从 底层架构 → 目录规则 → 核心概念层级 → 所有语法关键字拆解 → 触发事件 → 运行机器 → 并行 / 串行 → 完整实例逐行注释 → 秘钥 / 环境变量 → 调试 全套讲透。
一、先搞懂整体架构层级（最重要，理解这个就通了）
GitHub Actions 整套体系层级从大到小：
- Workflow 工作流 对应一个
xxx.yml配置文件，一整套完整自动化流程 - Job 任务 一个 Workflow 可以有多个 Job，每个 Job 独立一台虚拟机
- Step 步骤 一个 Job 由多个 Step 组成，从上到下顺序执行
- Action 动作 Step 里可直接调用别人写好的可复用模板（不用自己敲命令）
层级关系简图：
1个 yml工作流文件
├─ Job1（独立虚拟机）
│ ├─ Step1 拉代码
│ ├─ Step2 装依赖
│ └─ Step3 跑测试
└─ Job2（另一台独立虚拟机，默认和Job1同时跑）
├─ Step1 打包
└─ Step2 部署二、目录强制规则（为什么必须放这里）
必须严格固定路径，不能改名字、不能换位置：
仓库根目录
└── .github
└── workflows 【固定死，必须叫这个】
├── ci.yml
├── deploy.yml
└── cron.yml- GitHub 是硬编码识别这个文件夹，放别的目录不会生效
- 里面可以放无数个 yml 文件 ，每个文件完全独立、互不干扰
- 后缀只能是
.yml/.yaml
三、Runner 运行机器是什么？
Job 实际跑在的服务器，叫 Runner（运行器），分两种：
1. GitHub 托管 Runner（普通人都用这个，免费）
每次触发工作流，GitHub 临时给你开一台全新虚拟机，跑完立刻销毁，环境干净隔离。常用系统：
ubuntu-latest（最常用）windows-latestmacos-latest
2. 自建托管 Runner
把你自己的电脑 / 服务器接入 GitHub，任务跑在你自己机器上，适合内网项目、特殊环境。
四、Workflow 所有核心关键字 逐字详解
给你标准模板，逐个字段翻译 + 作用：
bash
# 1. 整个工作流的名字，显示在 GitHub Actions 页面
name: 前端CI自动测试
# 2. on：【核心】什么时候触发这个工作流
on:
push:
branches: [main, master]
pull_request:
branches: [main]
# 3. jobs：定义所有任务
jobs:
# jobID：自定义任务标识（随便起名）
test-job:
# 任务显示名称
name: 代码测试任务
# 在哪种系统上跑
runs-on: ubuntu-latest
# 依赖其他任务（做串行执行，后面讲）
needs: []
# 4. steps：当前任务的每一个步骤，按顺序执行
steps:
# 步骤1：调用官方Action拉取代码
- name: 拉取仓库代码
uses: actions/checkout@v4
# 步骤2：执行原生 shell 命令
- name: 安装依赖
run: npm install
# 步骤3：带条件执行
- name: 仅主分支打包
if: github.ref == 'refs/heads/main'
run: npm run build关键字逐个解释
| 关键字 | 作用 |
|---|---|
name |
工作流 / 任务 / 步骤 的展示名称 |
on |
触发条件：什么时候自动跑 |
jobs |
定义一组并行 / 串行任务 |
runs-on |
指定运行的系统虚拟机 |
needs |
任务依赖，控制执行先后顺序 |
steps |
单个任务里的步骤列表 |
uses |
调用现成的 Action 模板 |
run |
执行原生终端命令 |
with |
给 Action 传配置参数 |
if |
条件判断，满足才执行当前步骤 / 任务 |
五、on 触发事件 全场景详解
on 是最常用、最容易写错的，给你直接可用的 6 种写法：
- 所有代码推送都触发
bash
on: push-
提交 PR 合并请求才触发
on: pull_request
-
同时监听 push 和 PR
on: [push, pull_request]
-
只监听指定分支
on:
push:
branches: [main, master]
pull_request:
branches: [main] -
定时任务（Cron 表达式，UTC 时间）
on:
schedule:
- cron: '0 0 * * *' # 每天零点执行 -
手动点击按钮触发页面上点一下就跑，适合手动部署
on:
workflow_dispatch:
六、Job 并行 vs 串行
1. 默认：并行执行
两个 Job 不写 needs，同时开两台虚拟机一起跑
bash
jobs:
test:
runs-on: ubuntu-latest
steps: ...
deploy:
runs-on: ubuntu-latest
steps: ...2. 配置依赖：串行执行
让 deploy 必须等 test 跑完再执行
bash
jobs:
test:
runs-on: ubuntu-latest
steps: ...
deploy:
needs: test # 依赖 test 任务
runs-on: ubuntu-latest
steps: ...七、环境变量 & 私密密钥 Secrets
1. 普通环境变量
全局可用：
env:
NODE_ENV: production
jobs:2. 私密变量（重点）
仓库 → Settings → Secrets and variables → 加变量用来存 服务器密码、Token、密钥，日志里不会明文泄露使用方式：
run: echo ${{ secrets.SERVER_TOKEN }}八、最常用内置 Action（必记）
不用自己写复杂命令，直接调用官方轮子：
actions/checkout@v4：必用，把仓库代码拉到虚拟机actions/setup-node@v4：自动安装指定 Node 版本actions/setup-python@v5：自动安装 Pythonactions/upload-artifact：把打包产物上传保存actions/download-artifact：下载之前保存的产物
九、在哪里看运行日志、调试
- 仓库顶部导航 → Actions
- 左边看到所有 Workflow 列表
- 点进去能看：哪个 Job 失败、哪一步报错、完整日志
- 改完 yml 推送到仓库，自动重新触发测试
十、workflows 能干什么（实际落地场景）
- CI 持续集成：提交代码自动编译、自动跑单元测试、代码格式检查
- CD 持续部署：合并到主分支后，自动打包、自动部署到服务器 / 云平台
- 定时任务：每天定时备份数据库、定时爬取数据、定时清理日志
- 仓库自动化：PR 自动检查、自动打标签、自动关闭无效 Issue
十一、一句话总结
.github/workflows是 GitHub 固定专属目录，不能改名换位- 里面每个 yml = 一个 独立自动化工作流
- 结构：
on触发 → jobs任务 → steps步骤 → run/action执行 - 本质就是：不用自己服务器，GitHub 帮你免费跑自动化脚本