GitHub Actions 入门实战：3 步搭出自动部署流水线

每次改完代码都要手动打包、传服务器、重启服务，改得越勤、出错的概率越高。GitHub Actions 就是 GitHub 自带的自动化工具：代码一推送，它就按你写好的流程自动测试、打包、部署。下面用 3 步搭出一条能跑的流水线。

1. 在仓库里放一个工作流文件

在仓库根目录新建 .github/workflows/deploy.yml，这是流水线的全部定义：

name: deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 安装依赖
        run: npm install
      - name: 运行测试
        run: npm test

on.push.branches 规定只有推到 main 分支才触发；runs-on: ubuntu-latest 是运行环境；steps 里每一步就是一条命令。文件一提交，流水线立刻生效，不用再装任何插件。

2. 让流水线先做检查，再做部署

直接部署最怕的是“本地能跑、线上挂掉”。正确顺序是先检查、再部署，检查不过就停下：

      - name: 代码检查
        run: npm run lint
      - name: 构建产物
        run: npm run build
      - name: 部署到服务器
        run: scp -r dist/* user@server:/var/www/app/

测试、代码检查、构建三步任何一步失败，后面的部署都不会执行，坏代码到不了线上。scp 那一步要用到服务器密码或密钥，千万别写进 yml 文件里——用仓库 Settings → Secrets and variables → Actions 里存好的密钥，工作流里用 ${{ secrets.SERVER_KEY }} 引用。

3. 看懂一次运行记录

推代码后点仓库顶部的 Actions 标签，就能看到这次运行：绿色对勾是全过，红色叉是某一步失败。点进失败的那一步，日志会原样显示命令的输出，报错行一般就在最后几十行。修好代码再推一次，流水线会重新跑一遍，不用手动清掉上一次的记录。

刚开始可以只保留“安装依赖 + 运行测试”两步，跑通了再加构建和部署。流水线越短越容易排错，等它稳定跑上一两周，再把部署、通知这些步骤慢慢加上去。

小结

工作流文件定义触发条件和步骤，检查在前、部署在后，密钥只放 Secrets 不进代码。先让一条只有测试的流水线跑起来，再逐步加构建和部署——自动化部署不是一次搭完的，是先跑通、再加厚的。