Cloudflare Workers for Platforms 实战指南构建多租户隔离代码执行平台【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本文是面向开发者的一站式技术指南系统讲解 Cloudflare Workers for PlatformsWfP如何以 Dispatch Namespace Dispatch Worker User Worker Outbound Worker 四组件架构支撑多租户 SaaS、AI 生成代码沙箱执行、可编程平台等场景的隔离计算需求。读完本文你将掌握 WfP 的架构原理、命名空间与隔离模式配置、REST API/SDK 部署流程、路由与计费模式以及常见故障与平台限制的处理方法。本文基于本仓库skills/.curated/cloudflare-deploy/references/workers-for-platforms/目录下的 README.md 及其配套的 configuration.md、api.md、patterns.md、gotchas.md 整理而成。什么是 Workers for Platforms专为多租户而生Workers for Platforms 是 Cloudflare 提供的多租户平台方案其核心定位是在多租户架构中隔离执行客户代码并具备规模化能力。与常规 Workers 面向你自己写的代码不同WfP 面向的是运行客户或 AI 生成的代码这一场景让平台方可以把任意数量的用户 Worker 部署到同一个命名空间中由平台统一管控。本仓库的 cloudflare-deploy skill 在其决策树中也给出了明确指引见 SKILL.md当需求是运行代码且属于多租户客户部署代码时指向workers-for-platforms/普通服务端函数则走 workers/有状态实时协调走 durable-objects/。这说明 WfP 是一个定位清晰、与其他计算产品互补的独立架构。典型适用场景根据原文档以下场景适合使用 Workers for Platforms运行客户代码的多租户 SaaS在安全沙箱中执行 AI 生成代码带隔离计算能力的可编程平台边缘函数 / Serverless 平台静态 动态内容混合的网站构建器需要无限制应用部署规模化的平台。不适用于一般 Workers原文档特别强调WfP 不适用于普通 Workers 场景——它只服务于 Workers for Platforms 这一架构。如果你的需求只是运行自己的服务端逻辑应使用常规 WorkersV8 isolate 运行时支持 JS/TS/Python/Rust/WASM如果需要容器级隔离执行不受信任代码可评估 Sandbox每个沙箱 Durable Object Container。快速上手两种起步方式原文档提供了两条启动路径一键部署使用 Cloudflare 官方的Platform Starter Kitworkers-for-platforms-example 示例项目它内置了一整套完整的 WfP 环境Dispatch Namespace、Dispatch Worker 和一个用户 Worker 示例通过 Cloudflare 的一键部署按钮即可完成整站搭建原文档附带的 Deploy to Cloudflare 按钮即指向该仓库。手动搭建按 configuration.md 的步骤依次创建命名空间、配置 Dispatch Worker。对想理解底层原理的开发者本文后续的配置指南与API 操作手册两章即手动搭建的完整展开。核心能力一览原文档归纳的 WfP 关键特性如下每个命名空间无限制数量的 Workers没有普通 Workers 每账号 500 个的脚本数量限制自动租户隔离默认 untrusted 模式详见下文隔离模式可按客户自定义 CPU / 子请求subrequest限制主机名路由支持子域名 / 自定义域名出站 / 入站控制通过 Outbound Worker 拦截外部 fetch静态资源支持HTML/CSS/图片与 Worker 代码一同部署标签Tags用于批量操作每脚本最多 8 个。四组件架构与请求流WfP 的架构由 4 个组件构成理解它们之间的关系是掌握 WfP 的关键。1. Dispatch Namespace调度命名空间容纳无限量客户 Worker 的容器提供自动隔离能力。默认运行在untrusted 模式下Worker 无法访问request.cf对象也不共享缓存。命名空间可以按环境拆分最佳实践是每个环境一个命名空间如 production、staging。2. Dynamic Dispatch Worker动态调度 Worker整个平台流量的入口点负责路由请求并强制执行平台逻辑认证、限流、校验等。它通过绑定在env上的DISPATCHER对象按名字取出对应的用户 Worker。3. User Workers用户 Worker客户代码运行在隔离沙箱中通过 API 部署可按需绑定 KV、D1、R2、Durable Objects 等资源。4. Outbound Worker出站 Worker可选拦截用户 Worker 发出的外部fetch()请求实现出口egress控制、子请求日志记录。启用后同时会禁用 TCP Socket 的connect()API。请求流转过程Request → Dispatch Worker → Determines user Worker → env.DISPATCHER.get(customer) → User Worker executes (Outbound Worker for external fetch) → Response → Dispatch Worker → Client即请求先到达 Dispatch Worker由其确定目标用户 Worker 并通过env.DISPATCHER.get(customer)取出随后请求被转发给用户 Worker 执行若配置了 Outbound Worker用户 Worker 的外部 fetch 会先经过它响应沿原路返回客户端。决策树何时使用、路由策略与隔离模式原文档提供了三棵可直接套用的决策树这里完整保留并做注释。何时使用 Workers for PlatformsNeed to run code? ├─ Your code only → Regular Workers ├─ Customer/AI code → Workers for Platforms └─ Untrusted code in sandbox → Workers for Platforms OR Sandbox API即只运行自己的代码用常规 Workers运行客户或 AI 生成的代码用 WfP需要在沙箱中执行不受信任代码时在 WfP 与 Sandbox 之间按隔离粒度选择Sandbox 提供容器级隔离可执行任意进程命令详见其 README 中的sandbox.exec等 API。路由策略选择Hostname routing needed? ├─ Subdomains only (*.saas.com) → *.saas.com/* route subdomain extraction ├─ Custom domains → */* wildcard Cloudflare for SaaS KV/metadata routing └─ Path-based (/customer/app) → Any route path parsing三种路由策略的代码实现见下文Dispatch Worker 路由模式小节。隔离模式选择Worker mode? ├─ Running customer code → Untrusted (default) ├─ Need request.cf geolocation → Trusted mode ├─ Internal platform, controlled code → Trusted mode with cache key prefixes └─ Maximum isolation → Untrusted unique resources per customer配置指南本节对应 configuration.md覆盖命名空间绑定、隔离模式、CLI 命令、自定义限制、静态资源、标签与绑定配置。Dispatch Namespace 绑定在 Dispatch Worker 的wrangler.jsonc中声明命名空间绑定{ $schema: ./node_modules/wrangler/config-schema.json, dispatch_namespaces: [{ binding: DISPATCHER, namespace: production }] }绑定名默认为DISPATCHER之后即可在代码中通过env.DISPATCHER.get(name)取出用户 Worker。若要同时配置 Outbound Worker则在绑定中追加outbound字段见下文。Worker 隔离模式Untrusted 与 TrustedUntrusted默认命名空间中的 Worker 默认运行在 untrusted 模式以保证安全无request.cf对象访问权限每个 Worker 拥有独立缓存不共享缓存caches.default被禁用。Trusted信任模式仅当平台完全掌控所有代码如内部平台时开启。通过 REST API 修改命名空间配置curl -X PUT \ https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/dispatch/namespaces/$NAMESPACE \ -H Authorization: Bearer $API_TOKEN \ -d {name: $NAMESPACE, trusted_workers: true}开启后的注意事项Caveats命名空间内 Worker 会共享缓存因此必须使用缓存键前缀隔离如customer-${id}:${key}request.cf对象变为可访问开启 trusted 模式后需要重新部署已有 Worker才能生效。适用场景内部平台、A/B 测试平台、需要地理位置geolocation数据的场景。带 Outbound Worker 的绑定配置{ dispatch_namespaces: [{ binding: DISPATCHER, namespace: production, outbound: { service: outbound-worker, parameters: [customer_context] } }] }outbound.service指向出站 Worker 服务名parameters声明每次动态调度时传入出站 Worker 的参数名运行时通过env.DISPATCHER.get(worker, {}, { outbound: {...} })传值见 API 章节。Wrangler 命令命名空间管理wrangler dispatch-namespace list wrangler dispatch-namespace get production wrangler dispatch-namespace create production wrangler dispatch-namespace delete staging wrangler dispatch-namespace rename old new自定义 CPU 与子请求限制平台可为单次调用设置 CPU 时间与子请求数量上限在 Dispatch Worker 中按客户动态下发const userWorker env.DISPATCHER.get( workerName, {}, { limits: { cpuMs: 10, // 最大 CPU 毫秒数 subRequests: 5 // 最大 fetch() 调用次数 } } );处理限制违规try { return await userWorker.fetch(request); } catch (e) { if (e.message.includes(CPU time limit)) { return new Response(CPU limit exceeded, { status: 429 }); } throw e; }结合 patterns.md 中的按套餐计费模式可以做到 enterprise/pro/free 不同套餐下发不同limits如 enterprise 50ms/50 子请求、pro 20ms/20、free 10ms/5并在超限时用 Analytics Engine 记录违规数据点。静态资源部署WfP 支持将 HTML/CSS/图片与 Worker 一起部署。Wrangler 方式在wrangler.jsonc中声明 assets{ name: customer-site, main: ./src/index.js, assets: { directory: ./public, binding: ASSETS } }部署到指定命名空间npx wrangler deploy --name customer-site --dispatch-namespace productionDashboard 方式CLI 之外的备选在控制台上传 Worker 文件添加--dispatch-namespace标志wrangler deploy --dispatch-namespace production或在wrangler.jsonc的dispatch_namespaces下直接配置。程序化部署REST API / SDK 三步上传详见 api.md 与下文API 操作手册。Tags批量组织与检索每个 Worker 最多 8 个标签用于批量筛选与删除# 设置标签 curl -X PUT .../tags -d [customer-123, pro, production] # 按标签过滤 curl .../scripts?tagsproduction%3Ayes # 按标签删除 curl -X DELETE .../scripts?tagscustomer-123%3Ayes常用标签模式客户 IDcustomer-123、套餐级别free|pro|enterprise、环境production|staging。注意标签过滤时特殊字符必须 URL 编码如:写作%3A且应避免使用,与等特殊字符。Bindings为用户 Worker 注入资源支持 29 种绑定类型涵盖 KV、D1、R2、Durable Objects、Analytics Engine、Service、Assets、Queue、Vectorize、Hyperdrive、Workflow、AI、Browser 等。完整绑定类型参考见 bindings/ 文档。通过 API metadata 添加绑定{ bindings: [ {type: kv_namespace, name: USER_KV, namespace_id: ...}, {type: r2_bucket, name: STORAGE, bucket_name: ...}, {type: d1, name: DB, id: ...} ] }更新 Worker 时保留既有绑定避免更新导致绑定丢失{ bindings: [{type: r2_bucket, name: STORAGE, bucket_name: new}], keep_bindings: [kv_namespace, d1] // 保留这些类型的既有绑定 }API 操作手册本节对应 api.md覆盖用户 Worker 的部署、查询、删除、静态资源上传、Dispatch Worker 路由与 Outbound Worker 实现。部署用户 WorkerREST API使用 multipart 表单上传 ES Module 格式的 Workercurl -X PUT \ https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/dispatch/namespaces/$NAMESPACE/scripts/$SCRIPT_NAME \ -H Authorization: Bearer $API_TOKEN \ -F metadata{main_module: worker.mjs};typeapplication/json \ -F worker.mjsworker.mjs;typeapplication/javascriptmodule要点metadata 中指定main_module文件部分必须以application/javascriptmodule类型上传这也是 gotchas 中ES Modules 部署失败的根源与解法。TypeScript SDK 部署import Cloudflare from cloudflare; const client new Cloudflare({ apiToken: process.env.API_TOKEN }); const scriptFile new File([scriptContent], ${scriptName}.mjs, { type: application/javascriptmodule, }); await client.workersForPlatforms.dispatch.namespaces.scripts.update( namespace, scriptName, { account_id: accountId, metadata: { main_module: ${scriptName}.mjs }, files: [scriptFile], } );TypeScript 类型与动态调度选项import type { DispatchNamespace } from cloudflare/workers-types; interface DispatchNamespace { get(name: string, options?: Recordstring, unknown, dispatchOptions?: DynamicDispatchOptions): Fetcher; } interface DynamicDispatchOptions { limits?: DynamicDispatchLimits; outbound?: Recordstring, unknown; } interface DynamicDispatchLimits { cpuMs?: number; // 最大 CPU 毫秒数 subRequests?: number; // 最大 fetch() 调用次数 } // 使用示例 const userWorker env.DISPATCHER.get(customer-123, {}, { limits: { cpuMs: 50, subRequests: 20 }, outbound: { customerId: 123, url: request.url } });注意outbound对象中的键需要与wrangler.jsonc中outbound.parameters声明的参数名一致运行时才会注入到出站 Worker 的env中。带 Bindings 与 Tags 的部署curl -X PUT .../scripts/$SCRIPT_NAME \ -F metadata{ main_module: worker.mjs, bindings: [ {type: kv_namespace, name: MY_KV, namespace_id: $KV_ID} ], tags: [customer-123, production], compatibility_date: 2026-01-01 // 新项目请使用当前日期 };typeapplication/json \ -F worker.mjsworker.mjs;typeapplication/javascriptmodule列出与删除 Worker# 列出命名空间内所有 Worker curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/dispatch/namespaces/$NAMESPACE/scripts \ -H Authorization: Bearer $API_TOKEN # 按名称删除 curl -X DELETE .../scripts/$SCRIPT_NAME -H Authorization: Bearer $API_TOKEN # 按标签批量删除 curl -X DELETE .../scripts?tagscustomer-123%3Ayes -H Authorization: Bearer $API_TOKEN分页SDK 支持异步迭代手动调用时追加?per_page100page1查询参数。静态资源三步上传资源上传采用创建会话 → 上传文件 → 部署 Worker三步流程步骤 1创建上传会话提交文件清单manifestcurl -X POST .../scripts/$SCRIPT_NAME/assets-upload-session \ -H Authorization: Bearer $API_TOKEN \ -d { manifest: { /index.html: {hash: 08f1dfda4574284ab3c21666d1ee8c7d4, size: 1234} } } # 返回: jwt, bucketshash 计算规则SHA-256 截断为前 16 字节32 个十六进制字符。步骤 2上传文件使用上一步返回的 JWTcurl -X POST .../workers/assets/upload?base64true \ -H Authorization: Bearer $UPLOAD_JWT \ -F 08f1dfda4574284ab3c21666d1ee8c7d4BASE64_CONTENT # 返回: completion jwt多个 bucket通常 2 个用于冗余都需使用同一 JWT 与 hash 上传。步骤 3携带完成令牌部署 Workercurl -X PUT .../scripts/$SCRIPT_NAME \ -F metadata{ main_module: index.js, assets: {jwt: COMPLETION_TOKEN}, bindings: [{type: assets, name: ASSETS}] };typeapplication/json \ -F index.jsexport default {...};typeapplication/javascriptmodule资源隔离注意默认情况下静态资源在命名空间内共享。若需按客户隔离应对 hash 加盐sha256(customerId fileContents).slice(0, 32)。Dispatch Worker 路由模式子域名路由*.saas.com取 hostname 第一段作为用户 Worker 名export default { async fetch(request: Request, env: Env): PromiseResponse { const userWorkerName new URL(request.url).hostname.split(.)[0]; const userWorker env.DISPATCHER.get(userWorkerName); return await userWorker.fetch(request); }, };路径路由/customer/appconst pathParts new URL(request.url).pathname.split(/).filter(Boolean); const userWorker env.DISPATCHER.get(pathParts[0]); return await userWorker.fetch(request);KV 路由自定义域名 → KV 中查找映射const hostname new URL(request.url).hostname; const userWorkerName await env.ROUTING_KV.get(hostname); const userWorker env.DISPATCHER.get(userWorkerName); return await userWorker.fetch(request);Outbound Worker 实现配置在 Dispatch Worker 中传参const userWorker env.DISPATCHER.get( workerName, {}, { outbound: { customer_context: { customer_name: workerName, url: request.url } } } );实现Outbound Worker 收到用户 Worker 的外部 fetch 后可执行域名拦截、注入认证等逻辑export default { async fetch(request: Request, env: Env): PromiseResponse { const customerName env.customer_name; const url new URL(request.url); // 拦截恶意域名 if ([malicious.com].some(d url.hostname.includes(d))) { return new Response(Blocked, { status: 403 }); } // 注入认证头 if (url.hostname api.example.com) { const headers new Headers(request.headers); headers.set(Authorization, Bearer ${generateJWT(customerName)}); return fetch(new Request(request, { headers })); } return fetch(request); }, };注意Outbound Worker 不会拦截 Durable Object 与 mTLS 绑定的 fetch 调用规划出口控制时需要把这一点考虑进去。多租户模式与最佳实践本节对应 patterns.md。按套餐计费Plan-based Limits在 Dispatch Worker 中根据客户套餐动态下发资源限制interface Env { DISPATCHER: DispatchNamespace; CUSTOMERS_KV: KVNamespace; } export default { async fetch(request: Request, env: Env): PromiseResponse { const userWorkerName new URL(request.url).hostname.split(.)[0]; const customerPlan await env.CUSTOMERS_KV.get(userWorkerName); const plans { enterprise: { cpuMs: 50, subRequests: 50 }, pro: { cpuMs: 20, subRequests: 20 }, free: { cpuMs: 10, subRequests: 5 }, }; const limits plans[customerPlan as keyof typeof plans] || plans.free; const userWorker env.DISPATCHER.get(userWorkerName, {}, { limits }); return await userWorker.fetch(request); }, };资源级隔离需要完全隔离时为每个客户创建独立资源每客户一个 KV namespace、D1 数据库或 R2 bucketconst bindings [{ type: kv_namespace, name: USER_KV, namespace_id: customer-${customerId}-kv }];这与决策树中最大隔离 → Untrusted 每客户独有资源的策略对应。主机名路由详解通配符路由推荐在 SaaS 域名上配置*/*路由指向 Dispatch Worker。其优势同时支持子域名与自定义域名vanity domains没有普通 Workers 每账号 100 条路由的数量限制完全程序化控制兼容任意 DNS 代理设置。搭建步骤通过 Cloudflare for SaaS 配置自定义主机名配置 fallback origin若 Worker 作为源站可填占位 A 记录192.0.2.0DNS CNAME 指向 SaaS 域名*/*路由指向 Dispatch Worker在 Dispatch Worker 中实现路由逻辑export default { async fetch(request: Request, env: Env): PromiseResponse { const hostname new URL(request.url).hostname; const hostnameData await env.ROUTING_KV.get(hostname:${hostname}, { type: json }); if (!hostnameData?.workerName) { return new Response(Hostname not configured, { status: 404 }); } const userWorker env.DISPATCHER.get(hostnameData.workerName); return await userWorker.fetch(request); }, };仅子域名路由*.saas.com通配 DNS → origin*.saas.com/*路由 → Dispatch Worker提取子域名做路由。Orange-to-OrangeO2O行为当客户自己也在使用 Cloudflare 并 CNAME 到你的 Workers 域名时场景行为路由模式客户未使用 Cloudflare标准路由*/*或*.domain.com/*客户使用 Cloudflareproxied CNAME在边缘直接调用 Worker必须使用*/*客户使用 CloudflareDNS-only CNAME标准路由任意路由均可建议为保持一致的 O2O 行为一律使用*/*通配路由。Custom Metadata 路由Cloudflare for SaaS 场景下可将用户 Worker 名写入自定义主机名的custom_metadataDispatch Worker 读取后路由。要求自定义主机名必须是你的域名的子域名。可观测性Logpush在 Dispatch Worker 上启用可捕获所有用户 Worker 日志按Outcome或Script Name过滤Tail Workers实时日志支持自定义格式化接收 HTTP 状态、console.log()、异常与诊断信息Analytics Engine记录违规事件如 CPU 超限env.ANALYTICS.writeDataPoint({ indexes: [customerName], blobs: [cpu_limit_exceeded], });GraphQL查询按命名空间聚合的调用指标query { viewer { accounts(filter: {accountTag: $accountId}) { workersInvocationsAdaptive(filter: {dispatchNamespaceName: production}) { sum { requests errors cpuTime } } } } }典型用例实现AI 代码执行平台接收 AI 生成的代码并部署为用户 Worker同时对不受信任代码使用严格限制async function deployGeneratedCode(name: string, code: string) { const file new File([code], ${name}.mjs, { type: application/javascriptmodule }); await client.workersForPlatforms.dispatch.namespaces.scripts.update(production, name, { account_id: accountId, metadata: { main_module: ${name}.mjs, tags: [name, ai-generated] }, files: [file], }); } // 对不受信任代码使用严格限制 const userWorker env.DISPATCHER.get(sessionId, {}, { limits: { cpuMs: 5, subRequests: 3 } });AI 生成 部署平台还可结合 Cloudflare 的 VibeSDK原文档标注负责 AI 生成、沙箱执行、实时预览与部署。如果需求是容器级沙箱执行可参考仓库中 sandbox/ 的替代方案。边缘函数平台以路径段映射 Worker 名/customer-id/function-nameconst [customerId, functionName] new URL(request.url).pathname.split(/).filter(Boolean); const workerName ${customerId}-${functionName}; const userWorker env.DISPATCHER.get(workerName);网站构建器静态资源 Worker 代码组合部署资源 hash 加盐实现客户隔离完整实现见 api.md 静态资源章节。最佳实践清单架构每个环境一个命名空间平台逻辑认证、限流、校验全部收敛在 Dispatch Worker利用默认 untrusted 模式实现自动隔离路由使用*/*通配路由映射关系存 KV对不存在的 Worker 优雅处理返回 404限制与安全按套餐下发自定义限制用 Analytics Engine 追踪违规用 Outbound Worker 控制出口对响应内容做净化sanitize标签为所有 Worker 打上客户 ID、套餐、环境标签支持批量操作与高效过滤。常见错误与平台限制本节对应 gotchas.md是生产环境排错的第一手资料。常见错误与解决方案Worker not found试图获取命名空间中不存在的 Worker。捕获并返回 404try { const userWorker env.DISPATCHER.get(workerName); return userWorker.fetch(request); } catch (e) { if (e.message.startsWith(Worker not found)) { return new Response(Worker not found, { status: 404 }); } throw e; // 其余异常原样抛出 }CPU time limit exceeded用户 Worker 超过配置的 CPU 时间限制。用 Analytics Engine 记录违规并返回 429或按客户等级调整限制。主机名路由问题DNS 代理设置导致路由异常。改用*/*通配路由它在 orange-to-orange 路由下与代理设置无关。更新后绑定丢失更新 Worker 时未使用keep_bindings。在 API 请求中携带keep_bindings: true或列出要保留的绑定类型即可。标签过滤不生效过滤条件中的特殊字符未做 URL 编码。使用tagsproduction%3Ayes形式并避免,、等特殊字符。ES Modules 部署失败上传格式不正确。使用 multipart 表单上传metadata 中指定main_module文件类型设为application/javascriptmodule。静态资源上传失败hash 格式非法、令牌过期或编码错误。hash 必须是 SHA-256 前 16 字节32 个十六进制字符创建会话后 1 小时内完成上传上传完成后 1 小时内完成部署文件内容做 Base64 编码。Outbound Worker 未拦截调用Outbound Worker 不拦截 Durable Object 或 mTLS 绑定的 fetch。需据此规划出口控制方案。TCP Socket 连接失败启用 Outbound Worker 会禁用connect()API。Outbound Worker 只拦截fetch()需要 TCP 时移除 outbound 配置或改用代理模式。API 限流Cloudflare API 限流为每账号每 5 分钟 1200 次请求、每 IP 每秒 200 次。实现指数退避async function deployWithBackoff(deploy: () Promisevoid, maxRetries 3) { for (let i 0; i maxRetries; i) { try { return await deploy(); } catch (e) { if (e.status 429 i maxRetries - 1) { await new Promise(r setTimeout(r, Math.pow(2, i) * 1000)); continue; } throw e; } } }不支持渐进式部署dispatch 命名空间中的用户 Worker 不支持 gradual deployments。应使用一次性全量部署并在 Dispatch Worker 内通过功能开关、百分比路由等方式实现分阶段放量。资源会话过期上传 JWT 有效期 1 小时完成上传后的 completion token 同样 1 小时有效。大文件上传建议分批或提升并行度确保在时限内完成。平台限制汇总限制项数值说明每命名空间 Worker 数无限普通 Workers 每账号限 500 个每账号命名空间数无限最佳实践1 个 production 1 个 staging每 Worker 最大标签数8用于过滤与组织Worker 模式Untrusted默认trusted 模式才可访问request.cf缓存隔离每 Workeruntrustedtrusted 模式共享缓存需键前缀Durable Object 命名空间无限WfP 无每账号 DO 限制渐进式部署不支持仅一次性全量部署caches.default禁用untrusted使用 Cache API 自定义键资源上传限制限制项数值说明上传会话 JWT 有效期1 小时须在此时间内完成上传完成令牌有效期1 小时上传完成后须在此时间内部署资源 hash 格式SHA-256 前 16 字节32 个十六进制字符Base64 编码必需二进制文件必须编码API 限流限制类型数值作用域客户端 API每 5 分钟 1200 次每账号客户端 API每秒 200 次每 IPGraphQL视查询成本而定按查询复杂度操作限制操作限制说明CPU 时间自定义限制最高至 Workers 套餐上限在 Dispatch Worker 中按次设置子请求自定义限制最高至 Workers 套餐上限在 Dispatch Worker 中按次设置Outbound Worker 拦截范围不含 DO/mTLS仅拦截常规 fetch()TCP Socket启用 outbound禁用connect()API 不可用延伸阅读继续深入可依次阅读本模块的配套文档均在仓库skills/.curated/cloudflare-deploy/references/workers-for-platforms/目录下文件用途建议阅读时机configuration.md命名空间搭建、Dispatch Worker 配置首次搭建、调整限制api.md用户 Worker API、调度 API、Outbound Worker部署 Worker、SDK 集成patterns.md多租户、路由、出口控制模式架构规划、规模化gotchas.md限制、隔离问题、最佳实践排错、上线准备相关模块均位于skills/.curated/cloudflare-deploy/references/下workers/ —— 常规 Workers 运行时文档WfP 之前的入门基础durable-objects/ —— 有状态多租户模式sandbox/ —— 不受信任代码执行的替代方案容器级沙箱bindings/ —— 完整绑定类型参考。如果你是在本仓库的 cloudflare-deploy skill 上下文里工作可在 SKILL.md 的决策树中定位 WfP 的入口并参考其认证前置要求npx wrangler whoami验证登录CI/CD 场景设置CLOUDFLARE_API_TOKEN后再执行部署。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考