你还在手动敲命令部署？GitHub Actions 让你 push 即上线，摸鱼时间翻倍

你改完代码，打开终端，输入npm run build，然后 FTP 上传，或者登录服务器git pull。这一套操作每天重复 N 次，不累吗？今天我们来把“部署”这件事自动化——用 GitHub Actions，只要你git push，代码自动测试、自动打包、自动发到服务器。以后你只管写代码，上线交给机器人。

前言

我见过太多团队还停留在“手工部署”时代：上线先发个群消息“我要部署了，大家别动”，然后手动打包、上传、解压、重启。万一忘了执行某个步骤，线上就挂了。

GitHub Actions 就是你的免费 DevOps 机器人。它能监听 GitHub 上的事件（push、pull request、issue），然后执行你写好的自动化脚本。我们只需要写一个 YAML 文件，放在.github/workflows目录下，剩下的全部自动。

今天我们就来写一个完整的工作流：当推送到main分支时，自动运行测试、构建、并部署到服务器（或 Vercel / 阿里云 OSS）。全程保姆级，复制粘贴就能用。

一、准备工作：你需要什么？

• GitHub 仓库（私有或公开都可以）。
• 一台服务器（或云存储，如阿里云 OSS、Vercel）。
• 如果部署到自己的服务器，需要服务器的 SSH 密钥（免密登录）。

如果你没有服务器，可以用 Vercel（个人项目免费，连 GitHub 自动部署也是免费的，甚至不需要写 Actions——但为了教学，我们还是会演示自定义部署到服务器的流程）。

二、基础工作流：跑测试 + 打包

在项目根目录创建.github/workflows/deploy.yml：

name:CI/CD Pipelineon:push:branches:[main]# 当推送到 main 分支时触发pull_request:branches:[main]# PR 时也跑测试，但不部署jobs:test:runs-on:ubuntu-lateststeps:-name:检出代码uses:actions/checkout@v4-name:安装 Node.jsuses:actions/setup-node@v4with:node-version:18-name:安装依赖run:npm ci-name:运行测试run:npm testbuild:runs-on:ubuntu-latestneeds:test# 测试通过后才构建steps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:node-version:18-run:npm ci-run:npm run build-name:上传构建产物（给后续部署用）uses:actions/upload-artifact@v4with:name:distpath:dist/

提交这个文件后，每次git push main，GitHub 就会自动跑测试和构建。你可以在仓库的 Actions 标签页看到实时日志。

三、部署到自己的服务器（通过 SSH）

在deploy.yml中增加一个 job，依赖build，然后通过 SSH 把构建产物上传到服务器。

首先在 GitHub 仓库 Settings → Secrets and variables → Actions 中添加几个密钥：

• SERVER_HOST：你的服务器 IP
• SERVER_USERNAME：登录用户名（如 root、ubuntu）
• SSH_PRIVATE_KEY：服务器的私钥内容（复制~/.ssh/id_rsa整个内容）

然后在deploy.yml中添加：

deploy:runs-on:ubuntu-latestneeds:buildif:github.event_name == 'push'# 只有 push 时部署，PR 不部署steps:-name:下载构建产物uses:actions/download-artifact@v4with:name:distpath:dist-name:通过 SSH 部署uses:easingthemes/ssh-deploy@mainenv:SSH_PRIVATE_KEY:${{secrets.SSH_PRIVATE_KEY}}ARGS:"-rlgoDzvc -i --delete"SOURCE:"dist/"REMOTE_HOST:${{secrets.SERVER_HOST}}REMOTE_USER:${{secrets.SERVER_USERNAME}}TARGET:"/var/www/myapp/"# 服务器上的目标目录

这样，每次git push main，代码会自动出现在/var/www/myapp中。如果服务器上跑着 Nginx，刷新页面就是新版。

如果想要重启 PM2 进程，可以在部署步骤后加一个exec命令：

-name:重启 PM2 服务（如果后端是 Node）uses:appleboy/ssh-action@v1with:host:${{secrets.SERVER_HOST}}username:${{secrets.SERVER_USERNAME}}key:${{secrets.SSH_PRIVATE_KEY}}script:|cd /var/www/myapp pm2 restart myapp

四、部署到 Vercel（更简单）

如果你的项目是前端静态站点，Vercel 本身就是和 GitHub 集成的。但你也可以手动写 Actions 来调用 Vercel CLI。不过更推荐直接在 Vercel 网站导入 GitHub 仓库，它会自动监听 main 分支并部署，连 YAML 都不用写。

如果你坚持要用 Actions 调用 Vercel：

-name:部署到 Verceluses:amondnet/vercel-action@v20with:vercel-token:${{secrets.VERCEL_TOKEN}}vercel-org-id:${{secrets.ORG_ID}}vercel-project-id:${{secrets.PROJECT_ID}}vercel-args:'--prod'

五、部署到阿里云 OSS（静态网站托管）

阿里云 OSS 支持静态网站。我们可以用aliyun-cli同步文件：

-name:安装阿里云 CLIrun:npm install-g @alicloud/oss-name:同步到 OSSrun:|oss cp dist/ oss://my-bucket/ -r --force --access-key-id ${{ secrets.OSS_KEY_ID }} --access-key-secret ${{ secrets.OSS_KEY_SECRET }} --endpoint oss-cn-hangzhou.aliyuncs.com

六、进阶：分环境部署（dev/staging/prod）

你可以通过分支名来区分环境：

• main分支 → 生产环境
• develop分支 → 测试环境

在on.push.branches里可以写多个分支，然后在 job 里根据github.ref_name做判断，选择不同的服务器目录或环境变量。

七、常见坑点

• 密钥泄露：永远不要把 SSH 私钥、密码明文写在代码里，要用 GitHub Secrets。
• 构建产物太大：upload-artifact可能较慢，对于几 MB 的项目还好，几百 MB 建议直接推送到服务器或云存储。
• 权限问题：确保服务器上目标目录有写入权限。
• 缓存依赖：可以加actions/cache来缓存node_modules，每次 build 快很多。

八、总结：让机器人替你干活

• 写好.github/workflows/deploy.yml，push 即触发。
• 用 Secrets 存放敏感信息。
• 可以串联测试、构建、部署，还能加个钉钉/飞书通知。

从此你只需要git add . && git commit -m "fix: xxx" && git push，然后去倒杯水。回来群里就会收到：“生产环境部署成功，版本 v1.2.3”。不用记命令、不用等上传、不怕忘步骤。这才是现代前端该有的体验。

如果你觉得今天的“自动化”够解放双手，点个赞让更多人看到。评论区聊聊：你经历过哪些手工部署的惨案？