GitHub Actions网站自动更新

你有没有经历过这种场景：写了一篇文章，然后打开FTP工具，找到服务器上对应的目录，手动上传文件，再手动清理缓存。整个过程至少十分钟。如果是更新多篇文章或者改配置，搞半个小时都是常事。更崩溃的是，有时候忘记上传某个文件，网站直接报错。我刚开始做内容站的时候就经常遇到这种情况，后来实在忍不了，研究了一下GitHub Actions，把整个流程自动化了。现在从写完文章到上线，只需要做一件事——输入git push，然后回车。剩下的一切都是自动的。

GitHub Actions是GitHub提供的一个自动化工具，简单说就是一个跑在云端的机器人。你可以给它写一套指令：当某件事发生时，自动执行一系列动作。最常见的场景就是：当我把代码推送到main分支时，自动安装依赖、自动构建、自动部署到服务器。整个过程不需要人工干预。我和Vercel的这套组合就是把这个场景发挥到了极致。

为什么这个话题很重要

对比一下自动化和手动的效率差异就知道了。传统手动部署流程：写完文章后保存文件，打开FTP工具连接到服务器（有时还连不上），找到网站根目录（目录多的时候找半天），上传文件，检查有没有漏传，手动触发构建（如果是SSG框架），刷新CDN缓存。这一套下来，一篇文章至少30分钟。而用GitHub Actions加Vercel，流程变成了：git add、git commit、git push，然后等待30秒到1分钟，网站已经自动更新了。从30分钟到5秒，效率提升了360倍。

具体怎么配置？首先你的项目需要在GitHub上有一个仓库。然后在你仓库根目录下新建一个目录.github/workflows，在里面创建一个YAML文件，可以叫deploy.yml。这个文件就是告诉GitHub Actions什么时候做什么事。假如你用Vercel，其实更简单——Vercel支持直接和GitHub仓库集成，你不需要自己写复杂的deploy脚本，只需要在Vercel里关联你的GitHub仓库，Vercel会自动监听main分支的推送事件。每次有新的push，Vercel就自动拉取代码、安装依赖、执行构建、部署到生产环境。整个配置只需几分钟。

但如果你不用Vercel，或者你想在部署前后做一些额外的检查工作，GitHub Actions就很强大了。我自用的workflow是这样的：每次推送代码到main分支后，GitHub Actions先运行ESLint检查代码质量，再运行检查确保没有死链和错误的内部链接，然后用next build执行构建。如果构建成功，它会自动把构建产物部署到Vercel。如果构建失败，它会发送一个通知到我的飞书群里。这样即使我不在看电脑，也能知道部署状态。

第一步：找准定位

给你看一个实际可用的workflow配置示例。在你的仓库根目录下创建.github/workflows/deploy.yml文件，内容大致是这样的：name设为Deploy Website，on设定为push到branches:main，jobs里定义一个deploy job，runs-on用ubuntu-latest。steps依次是：checkout代码、setup Node.js（指定版本18或20）、npm ci安装依赖、npm run build构建、部署到Vercel（可以用vercel-action或者直接通过Vercel CLI）。重点是，每个step都有明确的失败处理机制，不会出现构建失败但还继续部署的情况。

对于用MDX来管理文章的人来说，GitHub Actions还可以帮你做更多事情。比如我写了一个脚本来检查所有文章文件的frontmatter是否格式正确，有没有缺失必填字段。如果新文章少写了description或者slug字段，构建就会失败，我会收到通知去修复。这大大减少了因为格式问题导致的部署失败。另外，我还在workflow里加了图片自动压缩的步骤——每次推送时扫描assets目录下的新图片，用sharp库自动转换成WebP格式并压缩到200KB以内，既节省了带宽也提升了页面速度。

有人可能会问：如果每次push都自动部署，万一推送了有问题的代码怎么办？这个担心很正常。GitHub Actions支持手动回滚。在Vercel的dashboard里，可以看到每一次部署的历史记录，点一下就能回滚到任意一个历史版本。这意味着你完全可以放心地push，出了问题回滚就完事了。

第二步：搭建系统

还有一个很实用的场景是定时发布。很多时候你可能在周末集中写了一批文章，想安排好时间每天发布几篇。GitHub Actions的schedule触发器可以帮到你。在workflow文件里on.schedule字段配置cron表达式，比如每天凌晨3点发布一篇文章。你可以把待发布的文章预先放在一个特定的文件夹里，用脚本控制每天自动移动一篇到发布目录，然后commit和push。当然，这个过程也可以通过分支管理来实现：在dev或者draft分支上写文章，用定时任务自动把draft分支的特定内容合并到main分支触发部署。

我自己的AgentClaw项目就是这套自动化流程的最好验证。从第一天上线到现在，每次内容的更新都是一个git push就搞定。写好的文章、生成的图片、修改的配置，全部通过Git管理。项目跑了几个月了，部署成功率接近100%。偶尔有构建失败的情况，基本是因为依赖版本变更或者代码格式问题，修复后重新push就行，耽误不了几分钟。

GitHub Actions还有一个被忽视的好处：它让你的项目有完整的版本历史。每一篇文章、每一次修改、每一个原子级别的变更，在Git日志里都清清楚楚。如果你哪天不小心删了文件，或者改了不该改的东西，随时可以git revert回去。传统FTP方式根本做不到这一点。用Git管理内容的变动，意味着你的一切操作都是可追溯、可回滚的。这对一人公司来说是一个巨大的安全感。

第三步：内容输出

如果你目前还没有在项目里配置GitHub Actions，我可以给你一个最低成本的启动方案。什么都不用改，只需要在Vercel的dashboard里关联你的GitHub仓库，设置自动部署。Vercel默认就会在每次push后自动构建和部署。你先体验一下那种"push完就发呆了10秒然后刷新页面内容已经更新"的感觉。等熟悉了Vercel的自动部署流程之后，再开始叠加GitHub Actions的额外功能，比如代码检查、图片优化、自动通知等。循序渐进，不要一上来就搞太复杂。

有些人的项目是部署在自建服务器或者自己买的云主机上的。这种情况下GitHub Actions依然可以用，只是部署目标不再是Vercel而已。你可以在workflow的最后一步通过SSH把你构建好的文件传到你的服务器上，然后远程执行重启服务的命令。前提是你的GitHub仓库需要配置好SSH密钥或者部署token。虽然比Vercel集成复杂一点，但自动化的思路是完全一样的。

说说成本。GitHub Actions免费版每个月的额度是2000分钟，对于个人项目来说完全够用。我每个月大概做100次左右的部署，每次构建耗时约2分钟，加起来200分钟，远低于免费额度。如果你需要更多的并发或者更长的运行时间，可以升级到Team计划，但对于一人公司来说免费版足够。Vercel的免费版也没有任何部署限制。所以整个自动化流水线的额外成本是零。

第四步：流量获取

最后我总结一下GitHub Actions给一人公司带来的核心价值。首先是效率：从写文章到上线只需要一个git push，省去了所有手动操作的环节。其次是可靠性：自动化流程按固定的规则执行，没有人会忘记上传文件。再次是可追溯：所有变更都有版本记录，出了问题随时回滚。如果你现在还在手动部署网站，我强烈建议花一个小时把自动部署流程配好。这一个小时的投入，未来会帮你省下无数个30分钟。

长期策略