Cloudflare 推出了 Worker Previews 服务，为每个 Git 分支提供独立的运行环境，使开发者能够在更接近生产环境的条件下测试代码变更，而不会影响工作版本的流量、配置或专属状态。该服务现已面向 Workers 用户开放。
每个预览都会获得一个固定的分支 URL，该 URL 会随着每次新的推送而更新，同时还拥有独立的配置、变量、密钥和绑定。开发者可以通过终端、持续集成系统或浏览器向预览发送请求，然后借助 Workers Observability 工具检查日志、错误、指标和执行追踪。
超越单纯版本链接的独立环境
Cloudflare 表示，Worker Previews 与此前的 Version URLs 不同。后者指向某个特定的已上传版本，并且可能使用生产资源；而 Worker Previews 会为每个分支创建隔离环境，并支持在一个控制面板中并行运行数百个预览。这使开发者能够在实际运行环境中测试 API 端点、用户界面变更和登录流程，而不只是检查代码或依赖共享的 staging 环境。
运行 npx wrangler preview 命令时，Cloudflare 会根据开发者在 Wrangler 文件中指定的基础配置创建预览版本。开发者可以修改特定预览的配置，例如让其连接测试数据库或使用测试 API 密钥，而不会改变生产环境或其他预览的配置。此外，还可以通过自定义域名提供预览地址，并使用 Cloudflare Access 对其进行保护和访问限制。
隔离状态和敏感资源
这种隔离也延伸至有状态资源。每个预览都拥有独立的 Durable Objects 空间和 Containers 应用，从而防止状态变更、会话、迁移操作或失败的架构变更影响生产环境或其他分支。Cloudflare 将这一行为与代码分支上下文关联起来：在生产环境中运行时，ctx.exports 会解析到生产空间；在实验分支中运行时，则会解析到相应的预览空间。
实际上，这允许开发者比较同一应用的不同配置，例如测试冷启动和热启动的性能，同时让每次实验的结果保留在各自的环境中。开发者还可以使用 Browser Run，在无界面浏览器中打开预览链接，执行登录流程并捕获屏幕截图或可重放会话，然后将用户看到的内容与记录的执行追踪和错误关联起来。
实际会发生什么变化？
Worker Previews 为每个分支提供了生产前反馈闭环：部署变更、运行、监控、修复故障，然后在合并前重新测试。Cloudflare 认为，这支持其所谓的代理开发生命周期，软件代理可以在同一分支范围内执行变更、检查变更并审查结果，并在需要时由人工审查员介入。
Cloudflare 曾在内部使用该服务测试 CloudflareOS 和 Gatekeepers，尤其是结合 OAuth、权限、批准和应用状态的流程。该公司还提到了 Supermemory 和 Ramp 在测试 Workers 变更以及通过移动设备审查合并请求方面的实践。
已公布的限制与后续步骤
目前，在多 Worker 应用中，预览无法隔离完整的请求链；例如，预览中的服务绑定可能会调用关联 Worker 的生产版本。此外，预览可以向 Queues 发送消息，但目前还不能消费这些消息；而要隔离 Workflows 的执行，则需要单独配置。Cloudflare 正在开发对这些路径的支持，同时还计划为 staging、QA 和持续运行的开发者环境提供长期预览。
certi.news 解读：此次公告的核心价值并不在于创建新的测试链接，而在于将隔离扩展到配置、状态和监控层面。这降低了测试涉及有状态资源的变更时所面临的风险，但并不意味着无需谨慎设计测试环境，尤其是在服务依赖多个 Workers、队列与消息以及长期运行的流程时。因此，Worker Previews 似乎比单独预览某个版本更加完整，但在当前版本中，应用的某些部分仍未纳入完整的隔离模型。