Skip to main content
部署工作流只读 GitHub Secrets,不读 Variables。添加位置:仓库 Settings → Secrets and variables → Actions → Secrets → New repository secret。
  • 一定要加在 Secrets 标签,加到 Variables 不会生效
  • 名称区分大小写(必须是 R2_MEDIA_BUCKET,不是 r2_media_bucket)
  • 值只填内容,不要写 NAME=...,一般不要加引号
  • 保存后无法再次查看原值,只能重新设置
  • 改完任何 Secret 都必须重新运行一次部署工作流——Secret 的修改不会自动同步到已部署的 Worker

必填项

这四项缺一个,部署就会直接停止。

CLOUDFLARE_API_TOKEN

  1. 登录 Cloudflare Dashboard
  2. 右上角头像 → My Profile → API Tokens
  3. Create Token → Custom token
  4. 配置权限:
  1. Create Token → 复制(仅显示一次)
格式:普通令牌字符串。
这个 Token 有两个用途:一是给 GitHub Actions 里的 wrangler 部署与 D1 迁移用;二是工作流会把它自动写成 Worker 的运行时 Secret CF_API_TOKEN,供 Worker 调 Cloudflare Cache Purge 接口清边缘缓存。所以如果想让「发布即清缓存」生效,权限里要勾上 Zone > Cache Purge。

CLOUDFLARE_ACCOUNT_ID

  1. 登录 Cloudflare Dashboard
  2. 选择任意域名(或看地址栏)
  3. 右侧栏 → API → Account ID
  4. 复制 UUID 格式的 ID
格式:32 位十六进制(如 a1b2c3d4e5f678901234567890abcdef)。

BLOG_D1_ID

输出示例:
复制 database_id 的值。 格式:UUID(带横线),例如 0fa366ac-f04a-4be2-8e11-5adc6ee6d686。
这个值不是数据库名(不是 blog),也不是 KV 的 id。工作流会做格式校验:去掉横线后必须是 32 位十六进制,否则直接报错中止。

BLOG_KV_ID

输出示例:
复制 id 的值。 格式:32 位十六进制(不含横线)。工作流同样会校验格式(长度必须是 32,字符只能是 0-9a-f),格式不对就直接报错中止。

推荐项

BLOG_ADMIN_SETUP_KEY

自行生成随机字符串:
格式:任意足够长的随机字符串。 它的作用有两个:
  1. 首次初始化管理员:配置后必须携带 X-Setup-Key 才能设置密码(杜绝「第一个请求到的人即拿管理员」的抢注竞态);未初始化时登录接口一律返回 403
  2. 登录限流的应急通道:登录请求带正确 X-Setup-Key 会跳过全部登录限流,但不跳过密码校验。所以站长永远有一条进得去的路
未配置时退化为旧行为:首次登录自动生成随机默认密码(xxxx-xxxx,标记 must_change),存在先到先得竞态。全新部署强烈建议配置。

SITE_URL

博客对外地址,如 https://www.2024921.xyz(末尾不要加 /)。 格式:带 https:// 的完整来源(origin),不带路径。 用途:
  • 生成 RSS / Sitemap 的链接前缀
  • 收紧 CORS:只允许「站点来源 + 请求自身来源」跨域读取
  • 评论 / 留言板提交时的来源校验
未配置 SITE_URL 时 CORS 是 fail-closed 的——不返回 Access-Control-Allow-Origin,跨站读取会被浏览器拦下(不是回显任意来源);RSS / Sitemap 则回退为用请求自身来源生成链接。所以正式站点请务必配置。

可选项

CF_ZONE_ID

自定义域名所在 Cloudflare Zone 的 ID。控制台 → 选中你的域名 → 右侧栏 API → Zone ID。 格式:32 位十六进制。 配置后与 CF_API_TOKEN(工作流自动写入)配合,文章增删改时按 Cache-Tag 清除边缘缓存(posts / feed / sitemap / post:<id> / stats:<id>)。按标签清除在 Free / Pro / Business / Enterprise 都可用(免费版 5 次/分钟、单次最多 100 个操作),详见 Cloudflare 缓存清除文档。不配置则依赖 s-maxage 自然过期,功能不受影响。

PAGES_PROJECT_NAME

名字有误导性:这个 Secret 实际的作用是覆盖 Worker 名称(部署命令追加 --name <值>),与 Pages 无关。不填则使用 wrangler.workers.toml 里的 kejiland。随意改名会部署出一个新的 Worker(域名 / 绑定都要重新配),新手建议不填。
格式:Worker 名称(字母 / 数字 / 连字符)。

BLOG_WRITE_TOKEN

旧式静态写入令牌。现在的写操作走会话 token(Authorization: Bearer <session-token>),BLOG_WRITE_TOKEN 仅作为兼容保留。新部署不需要。

BLOG_RATE_LIMIT_BINDING

一个正整数(如 1001),作为 Workers Rate Limiting 绑定的 namespace_id。 配置后会连锁触发两件事:
  1. 部署工作流改用 wrangler@^4.36.0(该绑定要求 ≥ 4.36)
  2. 向部署配置注入:
效果:登录接口在 Worker 入口按 IP 限流 10 次/分钟/位置,被拦下的请求不查库、不写库、不跑 PBKDF2。
详细的三层限流阈值与应急通道见 安全设计;三种边缘加固方案(Cloudflare Access / WAF 限流规则 / 本绑定)见 Cloudflare Workers 部署。

邮件订阅(可选)

Resend 相关变量四项齐全(RESEND_API_KEY、BLOG_MAIL_FROM、SITE_URL 为启用条件;BLOG_MAIL_REPLY_TO 可选)后,订阅、新文章通知、评论通知与群发邮件才可用。

内容、评论与 AI 开关(可选)

以上四项均由部署工作流在非空时自动写入 Worker,不需要再手动执行 wrangler secret put。

R2 存储(可选,8 个变量)

音乐与图片共用同一组凭据(代码只读取 R2_ACCESS_KEY_ID / R2_SECRET_ACCESS_KEY),所以这对凭据必须同时有权限访问两个桶。
R2 凭据、Endpoint 与桶名是分组生效的:音乐配置需要 R2_BUCKET;媒体配置需要 R2_MEDIA_BUCKET;备份配置需要 R2_BACKUP_BUCKET。若只配媒体桶,图片上传可用;音乐桶不完整时,音乐上传会回退到媒体桶。要让音乐 / 媒体 / 备份彼此隔离,请分别配置三个桶与公开域名(备份桶不要绑定公开域名)。
音乐桶的判定逻辑(代码层面):
也就是说:只要音乐桶的两个变量有一个为空,音乐就会自动落到媒体桶。发现音乐传到了媒体桶,先检查 R2_BUCKET / R2_PUBLIC_BASE 是否漏填。

由工作流自动写入的运行时变量

下面这个不是你填的 GitHub Secret,但很容易和上面的表混淆: BLOG_AI_ENABLED / BLOG_AI_PUBLIC、BLOG_ADMIN_EMAIL、COMMENT_BLOCKLIST、BLOG_PREVIEW_SECRET 与 R2 / Resend 相关变量都由工作流在非空时写入,不再需要手工 wrangler secret put。

配置步骤

  1. 进入 GitHub 仓库 → Settings
  2. Secrets and variables → Actions → Secrets 标签
  3. New repository secret → 填入 Name 和 Value
  4. 重复添加所有 Secret
  5. 重新运行一次部署工作流,让运行时 Secret 生效

延伸阅读