2026-08-24 · 定版方案

Cloudflare 钥匙定版
一线一把,五条权限

按"每条线都会有后端"来定版,一次配好、以后不用再动。所有结论都经过实测,不是照抄默认值。

标准权限包 · 有后端的业务线,五条权限,一模一样
  1. Account · Workers Scripts · Edit —— 把后端程序传上云
  2. Account · Workers KV Storage · Edit —— 新建/管理后端的缓存空间(实测:不给就建不了)
  3. Account · Cloudflare Pages · Edit —— 发报告站
  4. Account · Account Settings · Read —— 认出是哪个账号(只读)
  5. Account · Workers Tail · Read —— 看后端实时日志排障(只读)

范围一律 Include · 你的那个账号不要 Zone Resources;TTL 一年。
名字 业务线代号-deploy。没有后端的线(个人站)只留第 3 条,名 业务线代号-publish

领途那 13 条,逐条审过了

你问"当初开那么多是不是有原因"——我把领途整套查了一遍,没有隐藏原因。三条线索都指向同一个结论。

查了什么怎么查的结果
领途的插件、技能、本机脚本里有没有调 Cloudflare 接口 全仓搜 api.cloudflare.com / CLOUDFLARE_API_TOKEN / wrangler 一处都没有。只有一个 CLOUDFLARE_URL,那是站点网址字符串,不是钥匙
领途后端实际用了哪些云端零件 读配置文件 + 全文搜代码里的绑定 只有 KV 缓存(83 处)和 定时任务。没有 R2、D1、队列、容器、浏览器渲染、AI
有没有绑自定义域名(决定要不要 Zone 权限) 用领途那把有 All zones 权限的钥匙实查域名列表 账号下一个域名都没有 → Zone 权限不可能用得上

结论:那把钥匙唯一的用途就是你本机部署领途后端。13 条里有 9 条从来没被用到过——大概率是当初图省事按模板全勾了。

三个实验,定死了每一条该不该开

没有靠"看着像用不上"来判断。每条有争议的权限都用一把真钥匙实际跑了一遍。

实验做了什么结果与结论
实验一 只有 Pages·Edit 的 PawChibi 钥匙,真发一篇报告 ✅ 成功 → Account Settings·Read 不是必需(配置里写了账号编号就够)。留着只是保险,不是刚需
实验二 没有 Observability 权限的钥匙,部署一个开了日志记录的后端 ✅ 成功 → Workers Observability 确认可以删,即使以后要开日志也用不上它
实验三 没有 KV 权限的钥匙,新建一个 KV 缓存空间 ❌ 报鉴权错误 → 这是真缺口,必须补上 KV 权限
一处更正KV 这条:先前判断为"该删",现在改为"必须留"

先前的理由是"它能读出专家库缓存"——这个理由站不住。同一把钥匙已经有 Workers Scripts · Edit,也就是能改写后端程序;想拿 KV 里的数据,写一段代码部署上去就能拿到。

所以单独封住 KV,并不能真正保护那些数据,只会在新建后端时把你卡住——而三条线里已经有两条后端在用 KV,新后端要缓存是大概率事件。

画线的标准:已经在用、或几乎必然会用 → 加(KV 属于这类);没用也没计划用 → 不加,真用上那天补一条只要 1 分钟。

四把钥匙定版表

改完就是最终态,以后新建后端、换新电脑、加新业务线都不用再动它们。

现在定版后要做的动作
leadpath-deploy
13 条 + 所有域名
leadpath-deploy
标准 5 条
删 8 条 见下方清单;Zone Resources 整块删掉
junoandjett-deploy
3 条
junoandjett-deploy
标准 5 条
加 2 条 Workers KV Storage · EditWorkers Tail · Read
pawchibi-publish
1 条
pawchibi-deploy
标准 5 条
加 4 条 + 改名 PawChibi 有自己的后端(管 Shopify 那个白名单闸),一次配到位
austin-publish
1 条 · 所有账户
austin-publish
1 条 · 单账号
只改范围 个人站没有后端,权限不用加
为什么 austin-publish 不跟着升成 4 条

它对应的是你的个人报告站,没有后端、将来也不会有。给它 Workers 权限=白送一个"能改写你名下所有后端程序"的能力,没有任何收益。定版的统一是"规则统一",不是"每把长得一样"。

怎么改(三把,约 8 分钟)

最费事的一把leadpath-deploy · 13 条 → 5 条
✅ 留这 5 条
  • Account · Workers Scripts · Edit
  • Account · Workers KV Storage · Edit
  • Account · Cloudflare Pages · Edit
  • Account · Account Settings · Read
  • Account · Workers Tail · Read
❌ 删这 8 条(每行右边点
  • Workers Agents Configuration · Edit
  • Containers · Edit
  • Workers Observability · Edit (实验二证明用不上)
  • Workers Builds Configuration · Edit
  • Workers R2 Storage · Edit
  • User · Memberships · Read
  • User · User Details · Read
  • Zone · Workers Routes · Edit —— 账号下没有任何域名

删完那条 Zone 权限后,页面上的 Zone Resources(All zones) 整块也不再需要,一并删掉。

加一条junoandjett-deploy

+ Add more,加 Account · Workers Tail · Read。其余不动。

加三条 + 改名pawchibi-publishpawchibi-deploy
  1. ···Edit
  2. 点名字旁边的铅笔图标,改成 pawchibi-deploy
  3. 点四次 + Add more,依次加:Workers Scripts · EditWorkers KV Storage · EditAccount Settings · ReadWorkers Tail · Read
  4. Continue to summarySave

改名不影响钥匙的值,我这边配置不用动。

只改范围austin-publish

Edit 进去,Account ResourcesAll accounts 改成 Register@zenraki.com's Account。权限那一条不动。

为什么正好是这五条

权限干什么用凭什么说需要
Workers Scripts · Edit把后端程序传上云、设置里面锁的钥匙实测:J&J 后端就是用它部署成功的
Workers KV Storage · Edit新建/管理后端的缓存空间实验三:没有它,新建缓存空间直接报鉴权错误
Cloudflare Pages · Edit发报告站PawChibi 报告站每次发布都用它
Account Settings · Read让工具认出是哪个账号实验一证明非必需;只读、零风险,留着省得换机器时报"找不到账号"
Workers Tail · Read后端出问题时看实时日志只读。不给的话排障只能靠猜
明确不加的,以及为什么

Workers Observability——实验二证明开日志也用不上。
R2 存储 / D1 数据库 / 队列 / 容器 / AI——三条线后端一个都没用、也没有计划用。
Zone · Workers Routes——账号下一个域名都没有(实查过),不可能用得上。
User · Memberships / User Details——只是显示邮箱用,任何操作都不需要。

以后可能会想要的一条:Account Analytics · Read(看报告站有多少人点开)。现在没有任何技能在用,真想看数据时再加。

一个必须记住的边界

这五条权限的钥匙,永远只能待在你自己的机器上,绝不能放进任何后端里。

因为第 1 条能改写后端程序本身——后端里放着它,等于保险箱里放着自己的钥匙,被撬开一次就永久失守。将来若要让成员自助发报告,后端里只能锁单独一把、只有 Pages 权限的钥匙。