Cloudflare 工作流自动化教程｜附配置文件

在现代 Web 项目中，Cloudflare 早已不只是一个“CDN 加速服务”。它提供了 DNS、WAF、防火墙规则、缓存规则、Workers、Pages、R2、D1、Queues、Zero Trust 等一整套云原生能力。对于个人开发者和团队来说，如果仍然手动登录 Cloudflare 控制台进行配置，不仅效率低，而且容易出现环境不一致、误操作、配置遗忘等问题。

因此，将 Cloudflare 的配置纳入自动化工作流，是提升项目交付质量的重要一步。本文将以一个较完整的实践案例，介绍如何通过 Wrangler、GitHub Actions、配置文件和 API Token 实现 Cloudflare 工作流自动化，包括 Workers 部署、Pages 部署、环境变量管理、定时任务、缓存清理等内容。

一、为什么要做 Cloudflare 工作流自动化？

在实际项目中，Cloudflare 常见的人工操作包括：

• 手动创建 DNS 记录；
• 手动配置 Worker 路由；
• 手动部署 Cloudflare Workers；
• 手动发布 Cloudflare Pages；
• 手动配置环境变量；
• 手动清理缓存；
• 手动设置 Cron Triggers；
• 手动切换生产环境和测试环境；
• 手动维护不同项目的 Cloudflare 配置。

这些操作如果只做一次，看起来并不复杂。但当项目数量增加、环境变多、多人协作时，问题就会变得明显：

1. 配置不可追踪
   控制台中的修改很难通过 Git 记录，无法知道是谁在什么时候改了什么。

2. 环境不一致
   本地、测试、预生产、生产环境的配置可能不一致，导致线上问题难以排查。

3. 重复劳动严重
   每次新建项目都需要重复配置 DNS、Worker、Pages、缓存规则等。

4. 回滚困难
   如果误改了某项配置，手动恢复非常麻烦。

5. 不利于团队协作
   团队成员权限边界不清晰，容易出现过度授权。

通过自动化，我们可以将 Cloudflare 配置以代码形式管理，实现：

• 配置文件版本化；
• 部署流程标准化；
• 多环境自动切换；
• 自动发布与回滚；
• 降低人为误操作；
• 与 CI/CD 流程集成。

二、本文示例项目结构

本文以一个基于 Cloudflare Workers 的项目为例，同时兼顾 Pages 的自动化部署场景。项目结构如下：

cloudflare-automation-demo/
├── src/
│   └── index.ts
├── public/
│   └── index.html
├── wrangler.toml
├── package.json
├── tsconfig.json
├── .github/
│   └── workflows/
│       ├── deploy-worker.yml
│       ├── deploy-pages.yml
│       └── purge-cache.yml
└── README.md

其中：

• src/index.ts：Worker 入口文件；
• wrangler.toml：Cloudflare Workers 核心配置文件；
• .github/workflows/：GitHub Actions 自动化工作流目录；
• deploy-worker.yml：Worker 自动部署流程；
• deploy-pages.yml：Pages 自动部署流程；
• purge-cache.yml：缓存清理流程。

三、准备 Cloudflare API Token

自动化部署的核心是让 CI/CD 平台能够安全地访问 Cloudflare 资源。这里推荐使用 API Token，而不是 Global API Key。

1. 创建 API Token

登录 Cloudflare 后，进入：

My Profile → API Tokens → Create Token

你可以选择官方模板，也可以自定义权限。

对于 Workers 部署，常用权限如下：

Account - Workers Scripts - Edit
Account - Workers Routes - Edit
Account - Account Settings - Read
User - User Details - Read

如果涉及 Pages 部署，可以增加：

Account - Cloudflare Pages - Edit

如果需要清理缓存，还需要：

Zone - Cache Purge - Edit
Zone - Zone - Read

如果需要管理 DNS，则增加：

Zone - DNS - Edit
Zone - Zone - Read

2. 限制 Token 作用范围

创建 Token 时，建议限制到指定账号和指定域名，而不是开放全部权限。例如：

Account Resources:
Include - Your Account

Zone Resources:
Include - example.com

这样即使 Token 泄露，也能减少风险。

3. 保存到 GitHub Secrets

在 GitHub 仓库中进入：

Settings → Secrets and variables → Actions → New repository secret

添加以下密钥：

CLOUDFLARE_API_TOKEN
CLOUDFLARE_ACCOUNT_ID
CLOUDFLARE_ZONE_ID

其中：

• CLOUDFLARE_API_TOKEN：Cloudflare API Token；
• CLOUDFLARE_ACCOUNT_ID：Cloudflare Account ID；
• CLOUDFLARE_ZONE_ID：指定域名对应的 Zone ID。

Account ID 可以在 Cloudflare 控制台右侧找到。Zone ID 通常在具体站点概览页面右侧区域可以看到。

四、安装 Wrangler

Wrangler 是 Cloudflare 官方命令行工具，用于开发、测试和部署 Workers、Pages 等项目。

1. 初始化项目

如果你还没有项目，可以执行：

mkdir cloudflare-automation-demo
cd cloudflare-automation-demo
npm init -y
npm install wrangler typescript --save-dev

如果使用 TypeScript，还可以安装类型支持：

npm install @cloudflare/workers-types --save-dev

2. 查看 Wrangler 版本

npx wrangler --version

建议使用 Wrangler v3 或更新版本，因为 v3 对 Workers、Pages、D1、R2 等能力的支持更加完整。

3. 本地登录 Cloudflare

本地开发时可以执行：

npx wrangler login

CI/CD 环境中不需要登录，只需要通过环境变量提供 API Token。

五、编写 Worker 示例代码

创建 src/index.ts：

export interface Env {
  APP_NAME: string;
  ENVIRONMENT: string;
}

export default {
  async fetch(request: Request, env: Env): Promise {
    const url = new URL(request.url);

    if (url.pathname === "/health") {
      return Response.json({
        status: "ok",
        app: env.APP_NAME,
        environment: env.ENVIRONMENT,
        time: new Date().toISOString()
      });
    }

    return new Response(
      `Hello from ${env.APP_NAME}, environment: ${env.ENVIRONMENT}`,
      {
        headers: {
          "Content-Type": "text/plain;charset=UTF-8"
        }
      }
    );
  }
};

这个 Worker 很简单：

• 访问 /health 时返回 JSON 健康检查信息；
• 访问其他路径时返回文本；
• 使用环境变量区分应用名称和部署环境。

六、核心配置文件：wrangler.toml

wrangler.toml 是 Cloudflare Workers 自动化配置的重点。下面给出一个完整示例。

name = "cloudflare-automation-demo"
main = "src/index.ts"
compatibility_date = "2024-10-01"

account_id = "your_account_id"

workers_dev = true

[vars]
APP_NAME = "cloudflare-automation-demo"
ENVIRONMENT = "development"

[env.production]
name = "cloudflare-automation-demo-prod"
workers_dev = false
routes = [
  { pattern = "example.com/api/*", zone_name = "example.com" }
]

[env.production.vars]
APP_NAME = "cloudflare-automation-demo"
ENVIRONMENT = "production"

[env.staging]
name = "cloudflare-automation-demo-staging"
workers_dev = true

[env.staging.vars]
APP_NAME = "cloudflare-automation-demo"
ENVIRONMENT = "staging"

[triggers]
crons = [
  "*/30 * * * *"
]

配置说明

1. name

name = "cloudflare-automation-demo"

表示 Worker 名称。在不同环境中可以通过 [env.xxx] 覆盖。

2. main

main = "src/index.ts"

表示 Worker 入口文件。

3. compatibility_date

compatibility_date = "2024-10-01"

Cloudflare Workers 使用兼容日期控制运行时行为。建议明确设置，避免因平台更新导致不可预期变化。

4. account_id

account_id = "your_account_id"

本地配置可以直接写 Account ID。但如果希望避免在仓库暴露 Account ID，也可以在 CI 中使用环境变量。

5. workers_dev

workers_dev = true

表示是否启用 workers.dev 子域名访问。

6. 环境变量

[vars]
APP_NAME = "cloudflare-automation-demo"
ENVIRONMENT = "development"

普通变量可以写在 wrangler.toml 中。但敏感信息不要写在这里，例如数据库密码、Token、Webhook Secret 等。

敏感变量应该使用：

npx wrangler secret put SECRET_NAME

或者在 CI/CD 中通过命令写入。

7. 多环境配置

[env.production]
name = "cloudflare-automation-demo-prod"

部署生产环境时执行：

npx wrangler deploy --env production

部署测试环境时执行：

npx wrangler deploy --env staging

这样可以用同一套代码管理多个环境。

七、配置 package.json

创建或修改 package.json：

{
  "name": "cloudflare-automation-demo",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "dev": "wrangler dev",
    "dev:staging": "wrangler dev --env staging",
    "deploy": "wrangler deploy",
    "deploy:staging": "wrangler deploy --env staging",
    "deploy:production": "wrangler deploy --env production",
    "tail": "wrangler tail",
    "typecheck": "tsc --noEmit"
  },
  "devDependencies": {
    "@cloudflare/workers-types": "^4.20241018.0",
    "typescript": "^5.6.3",
    "wrangler": "^3.84.0"
  }
}

常用命令：

npm run dev
npm run deploy:staging
npm run deploy:production
npm run tail

八、TypeScript 配置文件

创建 tsconfig.json：

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "lib": ["ES2022"],
    "types": ["@cloudflare/workers-types"],
    "strict": true,
    "noEmit": true,
    "allowSyntheticDefaultImports": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*.ts"]
}

该配置适用于 Cloudflare Workers 的 TypeScript 开发环境。

九、GitHub Actions 自动部署 Workers

下面配置一个 Worker 自动部署流程：当代码推送到 main 分支时，自动部署到生产环境；当推送到 develop 分支时，自动部署到测试环境。

创建文件：

.github/workflows/deploy-worker.yml

内容如下：

name: Deploy Cloudflare Worker

on:
  push:
    branches:
      - main
      - develop
  workflow_dispatch:

jobs:
  deploy:
    name: Deploy Worker
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        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: Type check
        run: npm run typecheck

      - name: Deploy to staging
        if: github.ref == 'refs/heads/develop'
        run: npx wrangler deploy --env staging
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

      - name: Deploy to production
        if: github.ref == 'refs/heads/main'
        run: npx wrangler deploy --env production
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

工作流说明

这个流程完成了以下事情：

1. 拉取仓库代码；
2. 安装 Node.js；
3. 安装项目依赖；
4. 执行 TypeScript 类型检查；
5. 根据分支部署到不同环境。

如果推送到：

develop

则执行：

npx wrangler deploy --env staging

如果推送到：

main

则执行：

npx wrangler deploy --env production

十、自动部署 Cloudflare Pages

如果你的项目是静态站点，例如 Vite、Vue、React、Astro、Next.js 静态导出项目，也可以通过 GitHub Actions 部署到 Cloudflare Pages。

假设构建输出目录为：

dist

创建：

.github/workflows/deploy-pages.yml

配置如下：

name: Deploy Cloudflare Pages

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy-pages:
    runs-on: ubuntu-latest

    permissions:
      contents: read
      deployments: write

    steps:
      - name: Checkout repository
        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: Build site
        run: npm run build

      - name: Deploy to Cloudflare Pages
        run: |
          npx wrangler pages deploy dist \
            --project-name=cloudflare-automation-demo \
            --branch=main
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

如果是 Vite 项目，package.json 中通常会有：

{
  "scripts": {
    "build": "vite build"
  }
}

如果是 Astro 项目，则可能是：

{
  "scripts": {
    "build": "astro build"
  }
}

Pages 的优势是适合部署前端站点，而 Workers 更适合 API、边缘逻辑、鉴权、反向代理等场景。

十一、通过 GitHub Actions 自动清理缓存

网站发布后，有时需要主动清理 Cloudflare 缓存。可以通过 Cloudflare API 调用实现。

创建：

.github/workflows/purge-cache.yml

配置如下：

name: Purge Cloudflare Cache

on:
  workflow_dispatch:
    inputs:
      purge_type:
        description: "Purge type: everything or files"
        required: true
        default: "everything"
      files:
        description: "Files to purge, JSON array format"
        required: false
        default: "[]"

jobs:
  purge-cache:
    runs-on: ubuntu-latest

    steps:
      - name: Purge everything
        if: github.event.inputs.purge_type == 'everything'
        run: |
          curl -X POST "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE_ID}/purge_cache" \
            -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
            -H "Content-Type: application/json" \
            --data '{"purge_everything":true}'
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ZONE_ID: ${{ secrets.CLOUDFLARE_ZONE_ID }}

      - name: Purge specific files
        if: github.event.inputs.purge_type == 'files'
        run: |
          curl -X POST "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE_ID}/purge_cache" \
            -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
            -H "Content-Type: application/json" \
            --data "{\"files\":${FILES}}"
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ZONE_ID: ${{ secrets.CLOUDFLARE_ZONE_ID }}
          FILES: ${{ github.event.inputs.files }}

手动执行该工作流时，如果选择清理全部缓存，传入：

purge_type = everything

如果只清理指定文件，传入：

purge_type = files
files = ["https://example.com/index.html","https://example.com/assets/app.css"]

实际生产中，建议优先清理指定文件，而不是频繁清理全部缓存。因为清理全部缓存会导致短时间内大量请求回源，可能影响源站压力。

十二、自动配置 Secrets

Cloudflare Workers 中的普通变量可以写入 wrangler.toml，但敏感变量必须使用 Secret。

例如：

npx wrangler secret put API_SECRET --env production

如果希望在 GitHub Actions 中自动写入 Secret，可以这样做：

name: Sync Worker Secrets

on:
  workflow_dispatch:

jobs:
  sync-secrets:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install Wrangler
        run: npm install wrangler --save-dev

      - name: Put production secret
        run: |
          echo "${API_SECRET}" | npx wrangler secret put API_SECRET --env production
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          API_SECRET: ${{ secrets.API_SECRET }}

需要注意的是，Secret 一般不建议每次部署都写入，除非它确实会变化。更推荐单独建立一个手动触发的 Secret 同步工作流。

十三、配置定时任务 Cron Triggers

Cloudflare Workers 支持 Cron Triggers，可以用来执行定时任务，例如：

• 定时同步数据；
• 定时清理过期缓存；
• 定时发送统计数据；
• 定时检查服务状态；
• 定时刷新外部接口数据。

在 wrangler.toml 中配置：

[triggers]
crons = [
  "0 */6 * * *",
  "30 2 * * *"
]

然后在 Worker 代码中增加 scheduled 处理逻辑：

export interface Env {
  APP_NAME: string;
  ENVIRONMENT: string;
}

export default {
  async fetch(request: Request, env: Env): Promise {
    return new Response(`Hello from ${env.APP_NAME}`);
  },

  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise {
    ctx.waitUntil(handleCron(event, env));
  }
};

async function handleCron(event: ScheduledEvent, env: Env): Promise {
  console.log("Cron triggered:", {
    cron: event.cron,
    scheduledTime: event.scheduledTime,
    environment: env.ENVIRONMENT
  });

  // 在这里编写你的定时任务逻辑
}

部署后，Cloudflare 会按照配置的 Cron 表达式自动触发 Worker。

十四、使用环境变量管理不同环境

自动化工作流中，环境变量管理非常关键。建议按照以下规则处理：

示例：

[env.staging.vars]
ENVIRONMENT = "staging"
API_BASE_URL = "https://staging-api.example.com"

[env.production.vars]
ENVIRONMENT = "production"
API_BASE_URL = "https://api.example.com"

Worker 中读取：

export interface Env {
  ENVIRONMENT: string;
  API_BASE_URL: string;
}

export default {
  async fetch(request: Request, env: Env): Promise {
    return Response.json({
      env: env.ENVIRONMENT,
      api: env.API_BASE_URL
    });
  }
};

十五、自动化 DNS 配置示例

如果你希望进一步自动化 DNS 配置，可以通过 Cloudflare API 创建 DNS 记录。

下面是一个简单的 GitHub Actions 示例，用于创建或更新 CNAME 记录。

name: Upsert Cloudflare DNS Record

on:
  workflow_dispatch:
    inputs:
      record_name:
        description: "DNS record name"
        required: true
        default: "app.example.com"
      record_content:
        description: "DNS record content"
        required: true
        default: "target.example.com"

jobs:
  upsert-dns:
    runs-on: ubuntu-latest

    steps:
      - name: Find existing record
        id: find_record
        run: |
          RESPONSE=$(curl -s -X GET "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE_ID}/dns_records?type=CNAME&name=${RECORD_NAME}" \
            -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
            -H "Content-Type: application/json")

          RECORD_ID=$(echo "$RESPONSE" | jq -r '.result[0].id // empty')
          echo "record_id=$RECORD_ID" >> "$GITHUB_OUTPUT"
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ZONE_ID: ${{ secrets.CLOUDFLARE_ZONE_ID }}
          RECORD_NAME: ${{ github.event.inputs.record_name }}

      - name: Create DNS record
        if: steps.find_record.outputs.record_id == ''
        run: |
          curl -X POST "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE_ID}/dns_records" \
            -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
            -H "Content-Type: application/json" \
            --data "{
              \"type\":\"CNAME\",
              \"name\":\"${RECORD_NAME}\",
              \"content\":\"${RECORD_CONTENT}\",
              \"ttl\":1,
              \"proxied\":true
            }"
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ZONE_ID: ${{ secrets.CLOUDFLARE_ZONE_ID }}
          RECORD_NAME: ${{ github.event.inputs.record_name }}
          RECORD_CONTENT: ${{ github.event.inputs.record_content }}

      - name: Update DNS record
        if: steps.find_record.outputs.record_id != ''
        run: |
          curl -X PUT "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE_ID}/dns_records/${RECORD_ID}" \
            -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
            -H "Content-Type: application/json" \
            --data "{
              \"type\":\"CNAME\",
              \"name\":\"${RECORD_NAME}\",
              \"content\":\"${RECORD_CONTENT}\",
              \"ttl\":1,
              \"proxied\":true
            }"
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ZONE_ID: ${{ secrets.CLOUDFLARE_ZONE_ID }}
          RECORD_ID: ${{ steps.find_record.outputs.record_id }}
          RECORD_NAME: ${{ github.event.inputs.record_name }}
          RECORD_CONTENT: ${{ github.event.inputs.record_content }}

这个流程支持：

• 如果记录不存在，则创建；
• 如果记录已存在，则更新；
• 默认开启 Cloudflare 代理。

十六、生产环境建议

在实际生产环境中，建议遵循以下原则。

1. API Token 最小权限

不要使用全局 API Key。不同工作流应该使用不同 Token，例如：

• 部署 Worker 的 Token；
• 清理缓存的 Token；
• 管理 DNS 的 Token；
• 部署 Pages 的 Token。

这样权限边界更清晰。

2. 主分支部署前加入检查

生产部署前建议执行：

npm run typecheck
npm test
npm run lint

完整示例：

- name: Run checks
  run: |
    npm run typecheck
    npm run lint
    npm test

3. 使用 GitHub Environment 审批

对于生产环境，可以在 GitHub 中配置 Environment：

Settings → Environments → production

并启用人工审批。这样即使代码推送到 main，部署前也需要指定成员确认。

4. 避免频繁 Purge Everything

缓存清理应尽量精确，优先使用：

{
  "files": [
    "https://example.com/index.html"
  ]
}

而不是：

{
  "purge_everything": true
}

5. 关键配置不要硬编码

例如：

account_id = "your_account_id"

可以改为通过 GitHub Secrets 和环境变量管理。对于团队项目，这样更安全。

十七、常见问题排查

1. 部署时报错：Authentication error

通常是 API Token 权限不足或 Secret 配置错误。检查：

• CLOUDFLARE_API_TOKEN 是否正确；
• Token 是否过期；
• Token 是否限制了错误的 Account 或 Zone；
• 是否具备 Workers Scripts Edit 权限。

2. 找不到 Account ID

可以在 Cloudflare 控制台首页右侧找到，也可以使用 Wrangler 命令查看：

npx wrangler whoami

3. Worker 路由没有生效

检查：

• routes 中的域名是否正确；
• zone_name 是否与 Cloudflare 托管域名一致；
• DNS 是否开启代理；
• 是否部署到了正确的环境。

4. Secret 在 Worker 中读取不到

确认你是否部署到了同一个环境。例如你执行了：

npx wrangler secret put API_SECRET --env production

那么部署时也需要：

npx wrangler deploy --env production

5. Cron 没有触发

检查：

• wrangler.toml 是否配置 [triggers]；
• 是否重新部署；
• Cron 表达式是否有效；
• Worker 是否包含 scheduled 处理函数。

十八、推荐的完整配置清单

一个较完整的 Cloudflare 自动化项目，建议至少包含：

wrangler.toml
package.json
tsconfig.json
.github/workflows/deploy-worker.yml
.github/workflows/deploy-pages.yml
.github/workflows/purge-cache.yml

如果涉及更复杂的基础设施管理，还可以继续引入：

• Terraform；
• Pulumi；
• OpenTofu；
• Cloudflare API 脚本；
• GitHub Environment；
• GitHub OIDC；
• Monorepo 部署策略。

对于中小型项目，Wrangler + GitHub Actions 已经足够满足大部分自动化需求。

十九、总结

Cloudflare 工作流自动化的核心思想是：把控制台里的手动配置，尽可能转化为代码、配置文件和可重复执行的 CI/CD 流程。

本文介绍了一个较完整的自动化方案，包括：

• 使用 Wrangler 管理 Workers；
• 使用 wrangler.toml 管理多环境配置；
• 使用 GitHub Actions 自动部署 Worker；
• 使用 GitHub Actions 自动部署 Pages；
• 使用 API 自动清理缓存；
• 使用 Secret 管理敏感变量；
• 使用 Cron Triggers 实现定时任务；
• 使用 API 自动创建或更新 DNS 记录。

对于个人项目而言，这套流程可以减少重复操作；对于团队项目而言，它可以显著提升协作效率、部署稳定性和配置可追踪性。

如果你正在使用 Cloudflare Workers、Pages 或 Cloudflare DNS，建议尽早把配置纳入自动化流程。哪怕一开始只自动化部署和缓存清理，也能大幅降低维护成本。随着项目增长，再逐步加入 DNS 自动化、Secret 同步、多环境审批和基础设施即代码，会让整个 Cloudflare 使用体验更加工程化、稳定和安全。