01 它是干嘛的
Actions 是 GitHub 内建的自动化执行环境：把「提交代码之后要做的那些重复动作」写成一份放进仓库的配置文件，之后每次有人提交、提合并申请、打标签或按计划到点，平台就自动开一台机器把流程跑一遍。它解决的是「自动化脚本散落在仓库之外、没人知道它跑没跑」的问题。
02 为什么会有它
在 Actions 之前：流水线是脚手架上另搭的一间房
代码提交之后要做的事很多：跑测试、编译、打包、把产物传上去、通知相关的人。这些事人不该手动做，于是十几年来大家习惯在仓库旁边另搭一台「持续集成服务器」，用 Jenkins 之类的工具来管。
麻烦在于这间房和代码是分开的：流水线配置存在那台服务器上，写的人往往是团队里的专人；新人看不到、本地复现不了；服务器一挂，全队的自动化一起停；那台机器上的环境还会随时间慢慢和开发机跑偏，出现「服务器上能过、我本地过不了」的怪事。
2019 年 GitHub 把这件事收进了仓库本身：配置文件（一个 yaml 文件）就放在代码里，和代码一起评审、一起改版本；执行环境由平台按需临时创建，跑完即销毁，不会累积成一台没人敢动的老机器；凭据存在平台里而不是脚本里。自动化从此变成仓库的一个功能，而不是外部依赖。
03 它怎么工作
仓库里发生一个被配置监听的事件，平台照着 yaml 里的说明临时开一台机器，按顺序执行你写的步骤，结束后把结果贴回仓库，机器随即销毁。
一次提交是怎么自动跑完测试并发布的
- 1① 事件触发
提交代码、打开合并申请、打标签、定时任务等事件命中配置里的触发条件，流程被唤起。
- 2② 分配执行机器
平台按配置指定的系统类型，临时起一台干净的环境，不用你提前维护服务器。
- 3③ 拉代码与恢复缓存
把对应版本的仓库取下来，并取回上次留下的依赖缓存，避免每次都从零装一遍。
- 4④ 按顺序执行步骤
逐条跑你写的命令或现成的动作：装依赖、跑测试、编译打包、上传产物。
- 5⑤ 回报结果
成功或失败都写回这次提交与合并申请上，需要时用它阻断合并，或把产物发布出去。
04 谁在用它
每次提交自动跑单元测试与静态检查，问题在合并之前就被发现。
把流水线设置为合并的必过条件，测试不过就不允许合进主线。
打标签时自动编译、打包、生成版本，并上传到发布渠道或制品库。
按计划定时跑数据同步、依赖升级检查、健康巡检这类不需要人盯的活。
文档或静态站点仓库一提交就自动构建并部署，省掉手动上传这一步。
05 怎么用
会一点命令行，能读懂 yaml 的缩进即可开始；绝大多数场景都能找到现成的写法抄。
- 01在仓库里新建 .github/workflows 目录，放一个 yaml 文件进去。
- 02在文件里写清楚「什么时候触发」，比如只在向主分支提交合并申请时。
- 03指定运行环境（哪种系统），再按顺序写要执行的步骤。
- 04先在测试分支上推一次，观察执行日志，把报错的步骤逐条调通。
- 05把依赖缓存加上，后续每次执行会快很多。
- 06需要发布时，在最后加上打包与上传步骤，并把凭据配置到仓库的密钥里。
name: CI
# 什么时候跑：向主分支提合并申请时
on:
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm test避坑提示
- !凭据不要写在 yaml 里：放进仓库的密钥配置，执行时以环境变量注入。
- !给流水线加缓存，否则每次执行都从零装依赖，费用和时间都会翻倍。
- !把「测试必须通过」设为合并的硬性条件，不然流水线只是装饰，没人会去看。
06 关键概念
- 工作流（Workflow）
- 一份 yaml 描述的自动化流程，放在仓库的固定目录里，跟代码一起版本管理。
- 触发事件
- 什么情况下跑这条流程，例如提交、合并申请、打标签、定时。
- 任务与步骤
- 一条流程分成若干个任务，任务内部是一条条按顺序执行的步骤。
- 执行器（Runner）
- 真正干活的临时机器：平台按需创建，跑完销毁，不会越用越脏。