Cloudflare Worker 请求隔离入门
Cloudflare Worker 用 V8 Isolate 而非容器做请求隔离，把冷启动从秒级压到毫秒级。
Key Takeaways
- Isolate = 独立 V8 沙箱,拥有自己的全局对象、堆和调用栈
- 边缘节点复用 Isolate 池,冷启动 < 5ms
- 顶层变量会跨请求"泄漏"——隔离边界最常被踩的坑
- 状态外置到 KV / D1 / Durable Objects,Isolate 只做无状态计算
你打开部署在 Cloudflare Worker 上的网站时,平台不会"开一台新服务器"。请求会落到一个空闲的 V8 Isolate——一个轻量级 JavaScript 沙箱,拥有自己的全局对象、堆和调用栈,与同时刻到来的其他请求完全隔离。Isolate 之间无法访问彼此的内存,这是请求隔离的物理基础。
关键在"复用"。Cloudflare 在全球 300+ 边缘节点维护预热的 Isolate 池,新请求直接挂载到已有实例执行,不必从零初始化 V8。冷启动从传统容器/函数的数百毫秒压缩到 5ms 以内——用户几乎感觉不到等待。
flowchart LR
Req[请求] --> Edge{边缘节点路由}
Edge -->|空闲| I1[Isolate #1]
Edge -->|空闲| I2[Isolate #2]
Edge -->|全忙| Q[排队等待]
I1 --> Store[(KV / D1 / DO)]
I2 --> Store
Store --> Resp[响应返回]但有个微妙陷阱:同一个 Isolate 实例在生命周期内会串行处理多个请求,Isolate 内的全局变量、模块级变量在请求之间是共享的。如果你在 Worker 脚本顶层写了 let counter = 0,下一次请求会读到上一次的累计值——这是请求隔离边界最常见的漏洞,也是初学者最常踩的坑。
因此 Worker 的最佳实践非常清晰:把可变状态外置到 KV、D1 或 Durable Objects 等外部存储,让 Isolate 只承担无状态计算;同时避免在 fetch 处理器外做累加、单例缓存等"看起来很自然"的写法。理解这一点,你就抓住了 Worker 与传统 Node 服务器在并发模型上的本质差别。
---
References: