Cloudflare藏了3年的动态沙盒

2026年3月，Cloudflare扔出一个功能，让一批开发者当场愣住：原来用户存在数据库里的JavaScript代码，现在可以直接拉出来执行，还自带沙盒隔离。这不是什么实验性功能，是正式上线的Dynamic Workers。一个做RSS自动发布的开发者Rick Cogley，从发现文档到跑通生产环境，只用了一个下午。

问题的起点很具体：他需要一个能格式化RSS内容成社交帖子的模板系统。模板来源五花八门——手写的、AI生成的、从博客复制粘贴的。但让这种来路不明的代码字符串直接跑在主Worker里，还能访问D1数据库和R2存储桶？等于把家门钥匙交给陌生人。

在此之前，开发者面临的是一个经典的三难困境。选项一：用eval()或new Function()执行代码，快是快，但和主进程共享内存，危险系数拉满。选项二：WebAssembly沙盒，隔离性够，但只能跑编译后的字节码，JavaScript的灵活性没了。选项三：单独部署一个微服务专门跑用户代码，架构复杂度直接翻倍，运维成本让人头大。

Dynamic Workers的解法是把选项一的表达力和选项三的隔离性，打包成选项二的简洁度。核心机制一句话：父Worker从代码字符串动态生成子Worker，每个子Worker独享一个V8 isolate，启动毫秒级，权限由父Worker显式控制。

代码层面干净得不像企业级功能。父Worker调用env.LOADER.load()，传入兼容性日期、入口模块、模块映射，以及最关键的globalOutbound: null——直接掐断所有网络访问。子Worker能碰什么，全凭父Worker一张清单说了算。

Rick Cogley的系统架构是典型的Cloudflare全家桶：Hono API框架、D1数据库、R2对象存储、KV键值对、Vectorize向量库，外加几个Workflow串联。他的RSS订阅系统里，feeds表早就预留了auto_post和auto_post_template两列，想法一直停在"等新条目进来就自动生成帖子"的阶段。

没有Dynamic Workers之前，这条路走不通。他只能把每个RSS源的格式化逻辑硬编码进Worker——formatEsoliaBlogPost()这种函数直接写死在部署包里。想改输出格式？重新部署。新增一个RSS源？重新部署。整个系统僵成一块铁板。

现在他的数据流变成这样：每15分钟cron触发，拉取订阅的RSS源；发现新条目且auto_post为true时，条目被送进Dynamic Worker沙盒；沙盒执行数据库存储的JavaScript函数，返回格式化后的帖子内容；验证通过后，生成OG图片，同步推送到Bluesky、Nostr和status.lol。

新增RSS源变成纯数据操作。写一段新的格式化函数，塞进数据库，API调一次，完事。不需要碰代码仓库，不需要CI/CD流水线，不需要担心格式错误把整个Worker搞崩——沙盒里的代码就算跑飞了，父Worker捕获异常，标记跳过，流程继续。

这个设计戳中了一个长期被忽视的痛点：边缘计算场景下，"代码即数据"和"安全执行"从来是互斥选项。Serverless平台让你快速部署，但部署本身仍是重操作；数据库能灵活存储，但存进去的代码只是死文本。Dynamic Workers把两者缝合，让代码在数据层和执行层之间自由流动。

沙盒的边界画在哪

V8 isolate是Google Chrome的JavaScript引擎核心，每个isolate拥有独立的堆内存和全局环境，进程级隔离。Cloudflare Workers本就基于isolate架构，Dynamic Workers只是把isolate的创建权从平台下发到用户手里。

关键控制点在于globalOutbound参数。设为null，子Worker变成网络孤岛；设为特定配置，可以放行对指定域名的请求。这种白名单思路和企业防火墙的逻辑一致——默认拒绝，显式放行。父Worker还能通过其他参数控制子Worker能访问哪些D1数据库、哪些R2存储桶，权限粒度细到单个资源。

Rick Cogley的配置是极端保守派：网络全断，只给计算。他的格式化函数只需要处理字符串模板，不需要调外部API，这种隔离程度刚刚好。如果某个RSS源需要抓取外部图片再生成帖子，他可以在那条记录的配置里单独开一个小口子，其他源不受影响。

启动速度是另一个隐藏优势。isolate的冷启动在毫秒级，比容器或虚拟机快两个数量级。这意味着Dynamic Worker可以"用完即走"——每次RSS条目处理完，沙盒销毁，资源归零。没有常驻进程的成本，也没有多租户环境下的侧信道攻击风险。

对比AWS Lambda的"自定义运行时"或Google Cloud Functions的"本地函数"，Dynamic Workers的差异化在于执行环境的生成方式。后两者需要预先打包部署，Dynamic Workers从代码字符串即时编译。这种"即时沙盒"模式更适合代码频繁变动、但架构相对稳定的场景——比如Rick的RSS格式化系统，模板天天改，执行框架半年不动。

生产环境的真实摩擦

Rick Cogley的部署并非一帆风顺。他遇到的第一个坑是模块系统。Dynamic Workers支持ES模块，但代码字符串里的import语句需要提前解析，父Worker要在modules参数里把所有依赖映射清楚。一个格式化函数如果引用了lodash或date-fns，这些库得作为独立模块传进去，不能指望子Worker自己npm install。

他的 workaround 是把常用工具函数封装成标准库，和主代码一起打包进数据库。模板开发者只能用这些"白名单工具"，自由度受限，但安全性可预期。这实际上创造了一种"受限方言"——JavaScript语法全支持，但标准库被裁剪过。

调试是另一个暗礁。子Worker的错误堆栈不会自动冒泡到父Worker，需要显式捕获和序列化。Rick在沙盒代码里包了一层try-catch，把错误信息格式化成固定结构返回，父Worker再决定是重试、跳过还是告警。这种"错误即数据"的设计，让监控系统和业务逻辑解耦。

性能方面，他做过粗略测算。处理一条RSS条目，Dynamic Worker的额外开销在5-10毫秒，主要是isolate创建和代码编译。相比硬编码方案的零开销，这是可接受的代价——换取的是部署灵活性和故障隔离。他的cron每15分钟跑一次，单次处理几十条条目，总延迟从秒级降到毫秒级，用户体验无感知。

一个意外的发现是缓存策略。V8 isolate的编译结果可以复用，父Worker可以把编译后的代码快照存进KV，下次相同模板直接唤醒，跳过编译阶段。Rick还没实施这个优化，但文档里的这个细节让他意识到，Dynamic Workers的设计者考虑过高频、重复执行的场景。

边缘计算的权限重构

Dynamic Workers的发布时机值得玩味。2026年3月，距离Cloudflare Workers首次上线已过去近八年，边缘计算市场从"新奇概念"变成"默认选项"。但直到此刻，平台才交出"用户代码安全执行"的答卷。

这八年里，开发者用各种土办法填补这个缺口。有人用QuickJS这种轻量级引擎自己搭沙盒，有人把用户代码塞进WebAssembly的线性内存，还有人干脆不做隔离、靠审计和法务条款兜底。每种方案都有代价：维护负担、性能损耗，或者法律风险。

Cloudflare的选择是把问题下沉到基础设施层。V8 isolate本就是Workers的根基，暴露isolate创建API，相当于把平台的底层能力原样输出。这种"能力平权"策略，让中小开发者也能获得Google级别的高强度隔离，而不需要自己养一个V8团队。

更深层的影响在于架构范式。传统的三层架构里，代码层和数据层泾渭分明：代码在Git仓库，经CI/CD到运行时；数据在数据库，被代码读写。Dynamic Workers模糊了这条边界——代码可以住在数据库里，运行时按需"唤醒"。这接近Lisp程序员念叨的"代码即数据"，但用工业级的沙盒做了安全加固。

Rick Cogley的RSS系统是这个范式的小规模验证。更大的想象空间在于AI Agent、插件系统、用户自定义工作流——任何需要"让不可信代码做有用的事"的场景。一个SaaS平台可以让企业客户上传自己的业务逻辑，跑在隔离沙盒里处理数据，既满足定制化需求，又不污染核心系统。

当然，边界条件还在摸索中。Dynamic Workers目前不支持持久化状态，子Worker每次启动都是干净 slate，适合无状态计算，不适合长事务。CPU和内存限制继承自Workers平台的配额体系，重度计算任务可能触发限流。这些约束决定了它不是所有场景的银弹，但恰好切中"轻量、高频、不可信代码"的甜蜜点。

Rick Cogley在博客末尾留了一句话：「现在我可以把格式化逻辑交给AI生成，直接存进数据库，让它在沙盒里跑。如果输出奇怪，跳过就行，主系统毫无感知。」这种"生成-隔离-验证"的流水线，会不会成为AI时代边缘计算的默认模式？