Cloudflare 推出 Worker Previews：为每次代码变更提供隔离预览环境
译注：本文翻译自 Cloudflare 官方博客，原文发布于 2026 年 9 月 22 日，作者为 Yomna Shousha、William Taylor 和 Nanda Syahrasyad。原文链接：https://blog.cloudflare.com/worker-previews/
在 staging 环境测试通过的改动，上线后却表现不一致，这是开发者最头疼的问题之一。Cloudflare 希望提供一个尽可能接近生产的环境，让开发者充分验证改动，确保其行为符合预期。随着 Agent 帮助开发者编写比以往更多的代码，改动规模变大，发布前需要测试的范围也随之扩大。理想情况下，这种测试不应拖慢 Agent 的速度，同时还要赋予它们承担更多开发生命周期任务的能力。
为此，Cloudflare 正式推出 Worker Previews。每个 Git 分支都会获得一个类生产的运行环境，拥有独立的代码、配置、URL、可观测性和状态。
每个分支独立环境
当开发者开始新功能开发时，第一步通常是从 main 分支切出。这样便拥有了代码的独立副本，改动不会影响生产环境。Worker Previews 将这一模型从代码扩展到了运行环境：每个分支获得独立的环境和 URL，可以同时运行数百个 Preview，彼此独立且不影响生产。
生产环境和每个 Preview 各自拥有独立配置，运行在各自的 URL 上。执行 npx wrangler preview 时，分支会获得一份已定义的 Previews 配置副本，在独立 URL 上运行，且同属一个 Worker。在控制台中，这类似于切换分支——点击 Worker 名称旁的面包屑导航（默认显示 Production）即可查看所有 Preview。
与 Wrangler environments 不同（后者每个环境都需要部署和管理独立的 Worker），Previews 将隔离性保留在同一个控制台视图中。每个 Preview 都作为 Worker 的真实版本运行。
隔离且持久的状态：Durable Objects 与 Containers
要让隔离性覆盖整个应用，有状态资源需要特殊处理。Durable Objects 采用单例模型：一个实例负责特定的对象 ID，并拥有其存储。如果 Preview 与生产共享同一个 DO 命名空间，不仅会读到过期数据，还可能实时修改正在服务线上流量的同一实例。
因此，每次执行 npx wrangler preview 时，Cloudflare 会自动为该 Preview 创建新的 Durable Object 命名空间和 Container 应用，确保失败的迁移或错误的 schema 变更仅局限于该分支。开发者只需导出类、添加迁移，并通过 ctx.exports 访问：
export class Counter extends DurableObject {}
export default {
async fetch(request, env, ctx) {
const id = ctx.exports.Counter.idFromName("demo");
const counter = ctx.exports.Counter.get(id);
return counter.fetch(request);
},
};在生产环境中，ctx.exports.Counter 解析为生产命名空间；在 Preview 中则解析为该 Preview 的命名空间。
测试、观测与修正
每个分支在独立环境中以独立 URL 运行后，开发者可以进入反馈循环，在改动到达生产前充分测试。可以向 Preview URL 发送流量——从终端、CI 探针、Agent，或手动点击。流量开始流动后，所有 Workers Observability 工具均可使用，并按各个 Preview 进行范围限定。每个请求命中 Preview 时，Workers Observability 会以瀑布图追踪其完整生命周期，包括 fetch 调用、绑定操作和 handler 调用。
为了让 Agent 拥有更多控制权，开发者可以让它们在无头浏览器中打开 Preview URL，逐步点击登录流程，并截图或将会话录制为可回放的 DOM 事件——借助 Browser Run 实现。审查者可以通过 Live View 实时观看会话，或在自动化需要判断时通过 Human in the Loop 介入。
这为 Agent 提供了足够证据，使其能够自主运行预生产循环：部署、用 Playwright MCP 打开 URL、点击、通过 Workers Observability MCP server 查询 trace、修补、重新部署并验证。每次迭代都限定在该分支内。
基础配置与按需覆盖
正如不必每次分支都从头配置代码，环境配置也不应重复。开发者可以在 Wrangler 配置文件的 previews 块中一次性设置基础配置：
{
"vars": {
"ENVIRONMENT": "production"
},
"r2_buckets": [
{
"binding": "UPLOADS",
"bucket_name": "prod-uploads"
}
],
"previews": {
"vars": {
"ENVIRONMENT": "preview"
},
"r2_buckets": [
{
"binding": "UPLOADS",
"bucket_name": "r2-staging"
}
]
}
}在控制台的 Worker → Settings 中，这会显示为 Production 和 Previews Base。设置基础配置后，从任意分支运行 npx wrangler preview 即可创建 Preview。如果 Worker 通过 Workers Builds 与 Git 连接，推送时会自动创建。可以仅针对单个 Preview 覆盖任意设置，而不影响生产、基础配置或其他 Preview。
自定义域名与访问保护
Preview URL 可以托管在自有自定义域名上，更贴近生产环境。例如应用运行在 example.com，登录分支的 Preview 可运行在 feature-login.previews.example.com。若需保持 URL 私密，可用 Cloudflare Access 保护 Preview，要求访问者先登录。
内部实践与客户反馈
Cloudflare 内部已在广泛使用 Worker Previews，尤其是在构建和测试 CloudflareOS 时。CloudflareOS 是用于安全连接 Agent 与企业系统的开源平台，让 Agent 通过 Gatekeepers 与 Google、GitHub、Slack 等服务交互。Gatekeeper 的改动尤为敏感，因为一个 bug 可能暴露数据或允许不应发生的操作。有些 bug 只有在 OAuth 回调、权限、审批流程和应用状态同时运行时才会出现。因此，Cloudflare 为每个待审查的改动部署 CloudflareOS 及其 Gatekeepers 的隔离 Preview，运行完整工作流，修复失败项，再次测试后才合并。
客户也出于同样的基本原因使用 Previews：有些问题只有在改动实际运行时才会显现。Supermemory 创始人 Dhravya Shah 表示：“在 Supermemory，我们大量使用 Cloudflare，Worker Previews 正是我们期待的那种开发者体验改进。对于 HTTP 流程，我们可以在 Worker 改动到达生产前进行预览，包括由 Durable Objects 支持的路由，从而更早发现问题，同时不拖慢发布速度。”