在云原生理念日益普及的今天，Serverless 架构不仅应用于后端计算，也深刻影响了前端静态站点的托管与发布模式。GitHub Pages 作为一种静态站点托管级别的 Serverless 架构，用户无需关注底层 IaaS 资源的维护。结合 GitHub Actions 提供的持续集成与部署（CI/CD）能力，开发者可以实现“基础设施即代码”，达到完全自动化与免运维的发布目标。

本文将基于官方 Actions 工具链，探讨如何构建一条无需配置 Token、免 Web UI 操作、且具备极高可迁移性的自动化部署流水线。

一、 核心理念：Serverless 与 IaC 的结合

1. 免运维的 Serverless 架构

传统的静态站点部署往往需要手动配置服务器、SSL 证书、CDN、负载均衡以及备份恢复等基础设施。而采用 GitHub Pages 方案，开发者无需购买域名、配置 DNS 和 HTTPS，甚至无需关注监控告警与高可用性问题，这些均由平台自动提供。

2. 基础设施即代码

基础设施即代码的子集——配置即代码，要求所有的变更操作都在配置文件中定义，并随源代码一同进行版本控制，从而免除在图形界面（GUI）中的手动交互。通过编写 GitHub Actions 工作流文件，我们将部署流程完全代码化，实现了声明式 API 的实践。

二、 自动化流水线设计与实现

为了实现完全自动化，我们需要摒弃传统的 Web UI 手动触发或第三方 Action，转而使用 GitHub 官方推出的 Actions 组件。

1. 工作流配置文件解析

以下是一个基于 VitePress 静态站点的完整工作流配置（page.yml）。该配置实现了完全自动化，将其复制到其他同类项目中无需任何修改，展现出极佳的可迁移性：

name: VitePress-Website Github Pages Deploy on: push: branches: - main workflow_dispatch: inputs: logLevel: description: 'Log level' required: true default: 'warning' env: TZ: Asia/Shanghai jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Pages uses: actions/configure-pages@v5 - uses: pnpm/action-setup@v4 name: Install pnpm with: version: 9 run_install: false - name: Setup Node uses: actions/setup-node@v4 with: node-version: 20 cache: 'pnpm' - name: Install dependencies run: pnpm install - name: Build documentation run: pnpm run docs:build - name: Upload pages artifact uses: actions/upload-pages-artifact@v3 with: name: 'github-pages' path: docs/.vitepress/dist deploy: needs: build permissions: pages: write id-token: write environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4

2. 官方 Actions 的优势

该流水线配置的核心优势在于使用了actions/upload-pages-artifact@v3和actions/deploy-pages@v4这两个 GitHub 官方推出的 Actions。

• 免配置 Token：由于使用的是官方部署组件，工作流会自动使用 GitHub 提供的默认密钥secrets.GITHUB_TOKEN，开发者无需在仓库设置中手动创建和配置 Personal Access Token。
• 免 Web UI 操作：将配置文件推送到 GitHub 仓库即可完成静态站点部署，无需在仓库的 Web UI 中手动开启 GitHub Pages 或配置环境。当推送到默认分支时，工作流会自动触发后续的 CI 和 CD 阶段。

三、 动态路径适配与构建

在 GitHub Pages 的默认域名下，站点 URL 通常会带有仓库前缀的子路径（如https://<username>.github.io/<repository-name>/）。如果使用绝对路径加载资源，极易导致 404 错误。

基于 IaC 的动态 Base 配置

为保证高可迁移性，不应在配置文件中硬编码仓库名，而是通过环境变量动态识别。以 VitePress 为例，可在config.ts中利用 GitHub Actions 注入的环境变量进行判断：

// @ts-ignore const basePath = process.env.GITHUB_ACTIONS === 'true' ? '/你的仓库名/' : '/'

其中，process.env.GITHUB_ACTIONS是 GitHub Actions 运行器提供的原生环境变量，当在 CI 环境中运行时，该变量的值为true。这样既保证了本地开发与生产部署的兼容性，也遵循了配置即代码的原则。

四、 持续部署生命周期

采用上述架构后，项目的变更迭代过程被极大简化。开发人员的操作可概括为以下几个阶段：

1. 开发与代码迭代：在本地进行功能开发与静态资源构建（如执行 Tree-shaking、代码压缩与 Cache busting 等操作）。
2. 代码提交：将变更通过git push提交至 GitHub 仓库的main分支。
3. 触发流水线：推送操作自动触发 GitHub Actions 流水线。
4. 持续集成（CI）：工作流自动拉取代码，安装依赖并执行构建指令，生成静态制品包。
5. 持续部署（CD）：将构建好的制品上传并部署至目标环境（github-pages环境）。
6. 站点发布：静态资源被分发至全球 CDN，站点正式更新上线。

通过这一系列连接的服务，代码的构建与部署完全自动化。如果构建或部署过程出现错误，也可以通过查看仓库的 Actions 运行记录来排查日志。唯一需要人工执行的动作，仅仅是初始的代码“推送”操作。

五、 总结

基于 GitHub Actions 与 GitHub Pages 的 Serverless 架构实践，将传统的繁杂运维工作转化为一次简单的代码推送。开发者只需专注于业务代码的迭代，平台即可自动完成从构建到部署的全流程。这种基于官方组件的完全自动化流水线，不仅免去了 Token 配置与 Web UI 交互的烦恼，更以其出色的可迁移性和免运维特性，成为了现代静态站点发布的理想方案。