我来给你分享几个实用的方案，帮你实现只允许通过CI/CD部署生产环境Worker，阻止开发者从本地直接推送：

1. 利用Cloudflare的细粒度角色权限控制 #

Cloudflare其实支持自定义用户角色，你可以给普通开发者分配仅能操作预发布（staging）Worker的权限，把生产Worker的编辑/部署权限只留给CI/CD专用的服务账号：

• 登录Cloudflare Dashboard，进入你的账户页面，找到「成员」选项
• 创建一个自定义角色，比如「Worker Staging Editor」，在权限列表里只勾选「Worker脚本编辑」，并限定这个权限仅作用于你的staging Worker（或者对应的资源组）
• 把普通开发者的账号都添加到这个自定义角色下，而生产Worker的编辑权限只分配给CI/CD用的专用账号

这样开发者用自己的账号登录Wrangler后，根本没有权限操作生产环境的Worker，自然没法从本地部署。

2. 使用CI/CD专属的API令牌 #

创建一个仅拥有生产Worker部署权限的API令牌，只在CI/CD流程中使用，绝不把这个令牌分发给开发者：

• 进入Cloudflare Dashboard的「我的个人资料」→「API令牌」页面
• 点击「创建令牌」，选择「自定义令牌」，然后添加「Worker脚本编辑」权限，指定这个权限仅适用于生产Worker所在的账户和域名
• 把生成的令牌存在CI/CD平台的环境变量里（比如CF_API_TOKEN），CI/CD执行部署时，通过wrangler deploy --env production命令，让Wrangler读取这个环境变量里的令牌
• 开发者本地的Wrangler用的是自己的账号凭据，没有这个生产权限的令牌，所以无法完成生产部署

3. 隔离Wrangler配置的环境凭据 #

在wrangler.toml里明确区分staging和production环境，并把生产环境的敏感配置只放在CI/CD环境中，不提交到代码仓库：

# wrangler.toml 示例
name = "my-worker"
account_id = "your-shared-account-id"

[env.staging]
name = "my-worker-staging"
route = "staging.yourdomain.com/*"
# 开发者本地可以配置自己的凭据访问staging

[env.production]
name = "my-worker-production"
route = "yourdomain.com/*"
# 生产环境的凭据不在本地配置，完全由CI/CD的环境变量提供

这样开发者本地的Wrangler即使有生产环境的配置，也没有有效的权限凭据，部署会被Cloudflare拒绝。

4. 补充：用预部署钩子做额外校验（可选） #

如果需要更严格的控制，你可以在Wrangler的部署流程里加自定义校验逻辑，比如检查当前环境是否是CI/CD环境：

• 编写一个简单的脚本，检查环境变量（比如CI=true，大部分CI平台会自动设置这个变量）
• 在wrangler.toml里配置pre_deploy钩子，让Wrangler在部署前执行这个脚本
• 如果脚本检测到不是CI环境，就终止部署流程

不过这个方法只能作为补充，因为开发者可以伪造环境变量，核心还是要靠前面的权限控制。

备注：内容来源于stack exchange，提问作者moze