Cloudflare 为每个 Git 分支提供独立的、类生产环境

Cloudflare Workers 此前已有针对特定上传版本的 Version URL，但这些 URL 只能指向生产资源，且不会为每次变更创建隔离环境，因此要安全地测试较大的变更，就意味着要么冒着影响共享暂存状态的风险，要么为每个环境单独搭建一个 Worker。随着智能体辅助开发推动更多、更大的变更进入流水线，需要在合并前进行更多测试，同时又不拖慢智能体。

Worker Previews 将分支模型扩展到代码之外：在任意分支上运行 npx wrangler preview 会创建一个隔离环境，该环境拥有自己的 URL 和配置，并继承一份可按分支覆盖的基础配置。更难的问题在于状态。Durable Objects 采用单例模型，即一个实例拥有其存储，因此如果 Preview 共享生产的命名空间，一次失败的迁移就可能修改线上流量。修复方法是：为每个 Preview 创建一个全新的 Durable Object 命名空间，并通过 ctx.exports 解析，使相同的代码在生产环境和 Preview 中访问不同的命名空间。

Cloudflare 在 CloudflareOS 上对该功能进行了内部试用（dogfooding）。CloudflareOS 是 Cloudflare 自己的开源平台，让智能体通过按权限划分范围的“Gatekeepers”与 Google、GitHub 和 Slack 等服务交互。Gatekeeper 缺陷、OAuth 回调、审批流程以及权限状态之间的不良交互，只有在整个系统一起运行时才会暴露，因此团队会为每个待审查的变更部署一个隔离的 CloudflareOS Preview，在合并前运行完整工作流。

将 Git 分支从代码扩展到环境和状态

为每个 Preview 自动配置新的 Durable Object 命名空间和 Container 应用，消除了 Preview 可能悄悄修改服务于生产流量的存储这一故障模式。

定义一份可复用的基础配置供 Preview 继承，并支持按分支覆盖，避免了像独立环境那样为每个分支从头重新配置密钥和绑定。

在 CloudflareOS 的 Gatekeepers 上进行内部试用，针对的是隔离的组件测试无法捕获缺陷的情况，因为该缺陷只有在 OAuth、权限和审批流程一起运行时才会出现。

按 Preview 划分可观测性范围，使故障可以从该分支自己的追踪和日志中诊断，而不是混入生产流量或其他进行中的变更。

当“在暂存环境正常、在生产环境出错”反复出现时，应让每个环境的配置都像代码分支一样廉价且隔离，包括大多数工具仍保持共享的有状态部分。

Cloudflare 列出了发布时仍存在的缺口：从 Preview 调用的服务绑定仍会调用所绑定 Worker 的生产部署，而不是匹配的 Preview；Preview 可以向 Queues 发送消息，但尚不能消费消息；用于持久暂存或 QA 环境的长期 Preview 仍在根据私有测试反馈确定范围。Worker Previews 现已在 Workers 平台上全面可用，较早的 Version URL 则保留为一种独立且范围更窄的机制，用于指向特定的已上传版本。