GitHub Actions怎么用？从编写Workflow到自动化测试与部署的实用指南
GitHub Actions可以在代码提交、合并请求等事件发生后自动执行任务。本文用Node.js项目演示如何编写最小Workflow，完成依赖安装、测试和结果保存，并进一步介绍Secrets、权限、日志排错、缓存、并发控制和矩阵策略。
GitHub Actions是一套基于事件执行自动化任务的机制，常用于持续集成和持续交付。它的配置文件通常放在仓库的.github/workflows目录中，文件格式为YAML。一次代码提交可以触发Workflow，Workflow再按照定义好的步骤完成检查、测试、构建或部署。
先理解Workflow、Job、Step和Runner
Workflow是一个完整的自动化流程，由一个YAML文件描述；事件触发器决定什么时候启动，例如向指定分支推送代码或创建合并请求。Workflow可以包含一个或多个Job，Job通常在相互隔离的运行环境中执行。每个Job由多个Step组成，Step可以运行命令，也可以调用可复用的Action。实际执行这些任务的计算环境称为Runner。
编写一个最小可运行Workflow
下面以Node.js项目为例。假设仓库已经有package.json，并且其中定义了test脚本。新建.github/workflows/test.yml：
name: Node.js tests
on:
push:
branches: [ main ]
pull_request:
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Save test result
if: always()
run: echo "Test job finished with status ${{ job.status }}"这里的push和pull_request是触发条件。actions/checkout负责取得仓库代码，setup-node准备Node.js环境，npm ci依据锁定文件安装依赖，最后由npm test运行测试。if: always()表示测试失败后仍执行保存结果这一步；它不会把失败的测试变成成功。
变量、Secrets与权限的区别
普通环境变量适合保存不敏感的配置，例如运行模式或目录名称，可以在Job或Step中通过env设置。Secrets用于令牌、云服务密钥等敏感值，应在仓库或环境的设置中配置，再通过${{ secrets.NAME }}读取。不要把密钥直接写进YAML、源代码或命令参数，也不要为了调试把它打印到日志。
permissions控制Workflow使用GitHub令牌访问仓库资源的权限。建议从较小权限开始，例如只读代码时使用contents: read；只有确实需要写入发布分支、创建评论或上传资源时，才增加对应权限。权限与Secrets不是同一类配置：前者限制令牌能做什么，后者提供需要保密的值。
失败时如何定位
- 先看失败的Step。展开日志，确认是依赖安装、测试命令、权限还是路径问题。把本地可复现的命令直接写入Step，通常比一次执行过多脚本更容易定位。
- 检查触发条件和分支。如果Workflow没有启动，先确认YAML文件位于正确目录，事件名称、分支名称和缩进是否正确。
- 核对运行环境。检查Node.js版本、包管理器和锁定文件是否匹配。不要只在本地使用未写入Workflow的全局工具。
- 合理使用失败重跑。修正配置或代码后再重跑；如果只是外部服务短暂异常，可以重跑失败任务，但不要把反复重跑当作修复方案。
缓存、并发与矩阵策略
依赖安装较慢时，可以使用对应Setup Action提供的缓存能力。缓存只能加速安装，不能替代锁定文件，也不应假设缓存内容永远存在。对于同一分支频繁提交的Workflow，可以配置并发组，让新运行取消仍在进行的旧运行，避免不必要的重复任务；是否取消应根据测试或部署场景决定。
如果需要在多个Node.js版本或操作系统上测试，可以使用矩阵策略，为同一个Job生成多组环境。矩阵适合验证兼容性，但会增加执行任务数量，应选择项目真正支持的版本组合。构建静态网站并发布到托管服务时，构建步骤和发布步骤可以拆成不同Job，并通过依赖关系保证构建成功后才发布，同时单独配置发布所需的环境和权限。
提交前检查清单
- YAML缩进、文件路径和触发分支是否正确。
- 安装命令是否使用项目实际的锁定文件。
- 测试失败时是否能从日志看出具体命令。
- Secrets是否通过安全配置注入，且没有出现在日志中。
- 权限是否按最小需要设置，部署任务是否与测试任务分开。
建议先用一个只运行测试的最小Workflow验证触发、环境和日志，再逐步加入缓存、矩阵和部署。这样每次增加配置都能明确判断问题来源，也更容易维护持续集成流程。
