Cloudflare Workers for Platforms 配置实战Dispatch Namespace、隔离模式与自定义限额完全指南【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本文是 Cloudflare Workers for PlatformsWfP多租户平台配置的完整实战指南围绕 dispatch namespace 的绑定配置、Worker 隔离模式切换、自定义 CPU/子请求限额、静态资源部署、Tags 批量管理以及 Bindings 注入展开。读完本文你将掌握如何通过 wrangler.jsonc 与 REST API 完成整套平台配置并理解 untrusted / trusted 两种隔离模式的取舍与底层行为差异。架构背景配置在整个四组件模型中的位置Workers for Platforms 专为运行客户代码的多租户平台设计——例如多租户 SaaS、AI 生成代码的沙箱执行、可编程边缘函数平台、网站搭建器静态 动态内容等场景。它不适用于只运行自己代码的普通 Workers 场景README。整个架构由 4 个组件构成而配置文档覆盖的是其中第 1 个组件及与之关联的运行约束Dispatch Namespace——容纳无限量客户 Worker 的容器默认 untrusted 隔离模式Dynamic Dispatch Worker——请求入口负责鉴权、限额、校验等平台逻辑User Workers——客户代码运行在隔离沙箱中通过 API 部署可挂载 KV/D1/R2/DO 等绑定Outbound Worker可选——拦截客户 Worker 的外部 fetch控制出网并记录子请求。请求流转链路为Request → Dispatch Worker → env.DISPATCHER.get(customer) → User Worker 执行 → (外部 fetch 经 Outbound Worker) → Response → Dispatch Worker → Client本指南中的每一项配置namespace 绑定、隔离模式、限额、静态资源、Tags、Bindings都在为这条链路提供服务下面逐一展开。Dispatch Namespace Binding 配置Dispatch Worker 通过名为DISPATCHER的绑定访问 namespace 中的任意客户 Worker。在wrangler.jsonc中声明如下原文档配置示例{ $schema: ./node_modules/wrangler/config-schema.json, dispatch_namespaces: [{ binding: DISPATCHER, namespace: production }] }配置要点$schema指向本地node_modules/wrangler/config-schema.json让编辑器与 CLI 获得配置校验与补全binding是 Dispatch Worker 代码中使用的绑定名绑定后即可通过env.DISPATCHER调用namespace指定绑定到的 namespace 名称。从仓库实践看最佳做法是每个环境一个 namespace如productionstaging各一个方便隔离与发布控制见 README 与 patterns。env.DISPATCHER的类型签名来自 api.md为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() 次数 }即在 Dispatch Worker 中env.DISPATCHER.get(workerName, {}, { limits, outbound })即可按客户动态下发限额与出网参数。Worker 隔离模式Untrusted 与 Trusted默认 Untrusted 模式namespace 中的 Worker 出于安全考虑默认运行在untrusted 模式具体表现为三条硬约束无法访问request.cf对象拿不到地理信息等请求上下文每个 Worker 拥有独立缓存namespace 内不共享缓存caches.default被禁用。这保证了即使某个客户代码被攻破也无法读取其他客户的数据或共享缓存。启用 Trusted Mode对于完全由你控制全部代码的内部平台可以显式开启 trusted 模式通过 REST API 修改 namespace 属性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}开启后需要特别注意的Caveatsnamespace 内 Worker 开始共享缓存必须用缓存键前缀隔离客户数据推荐格式customer-${id}:${key}request.cf对象变为可访问开启 trusted 模式后必须重新部署已有 Worker才能生效。何时使用 trusted内部平台、A/B 测试平台、需要地理位置geolocation数据的场景。凡是运行外部客户代码都应保持默认 untrusted。这一取舍在 README 决策树 中归纳为运行客户代码 → untrusted默认需要request.cf地理位置 → trusted内部平台且代码可控 → trusted 缓存键前缀追求最大隔离 → untrusted 每个客户独立资源。带 Outbound Worker 的配置当需要拦截客户 Worker 的外部 fetch 以控制出网时在dispatch_namespaces中补充outbound声明{ dispatch_namespaces: [{ binding: DISPATCHER, namespace: production, outbound: { service: outbound-worker, parameters: [customer_context] } }] }service指定出网拦截 Workerparameters声明在调用时透传给该 Worker 的参数名如customer_context。运行时在 Dispatch Worker 中通过dispatchOptions.outbound传入具体值const userWorker env.DISPATCHER.get( workerName, {}, { outbound: { customer_context: { customer_name: workerName, url: request.url } } } );Outbound Worker 内部通过env.customer_name等绑定拿到上下文可实现域名黑名单拦截、注入鉴权头等逻辑完整实现见 api.md。Wrangler 命令行管理 Dispatch Namespace配置完成后可用 wrangler 命令完成 namespace 的增删查改原文档命令清单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另外部署客户 Worker 到指定 namespace 的命令为见本文静态资源一节npx wrangler deploy --name customer-site --dispatch-namespace productionCustom Limits每次调用的 CPU 与子请求限额WfP 的核心能力之一是按调用动态控制客户代码的资源消耗。在 Dispatch Worker 中为单个用户 Worker 设置限额原文档示例const userWorker env.DISPATCHER.get( workerName, {}, { limits: { cpuMs: 10, // 单次调用最大 CPU 毫秒数 subRequests: 5 // 单次调用最大 fetch() 次数 } } );限额上界取决于你的 Workers 套餐计划额度见 gotchas.md 操作限额表可在限额内为不同客户档次设置不同值。限额违规处理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将客户计划存于 KV按 enterprise / pro / free 分别下发{ cpuMs, subRequests }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 });配合 Analytics Engine 将违规事件写为数据点即可对客户用量进行统计与告警env.ANALYTICS.writeDataPoint({ indexes: [customerName], blobs: [cpu_limit_exceeded], });部署静态资源WfP 支持随 Worker 一起部署 HTML/CSS/图片等静态资源有 CLI、Dashboard、REST API 三种途径。Wrangler 方式在wrangler.jsonc中声明资源目录与绑定{ name: customer-site, main: ./src/index.js, assets: { directory: ./public, binding: ASSETS } }然后部署到指定 namespacenpx wrangler deploy --name customer-site --dispatch-namespace productionDashboard 部署不熟悉 CLI 时的替代路径在 Dashboard 上传 Worker 文件通过--dispatch-namespace标志指定目标 namespacewrangler deploy --dispatch-namespace production或在wrangler.jsonc的dispatch_namespaces中预先配置。REST API 三步上传流程程序化部署走创建会话 → 上传文件 → 部署 Worker三步详见 api.md第一步创建上传会话提交资源清单hash 为 SHA-256 截断前 16 字节即 32 位十六进制字符curl -X POST .../scripts/$SCRIPT_NAME/assets-upload-session \ -H Authorization: Bearer $API_TOKEN \ -d { manifest: { /index.html: {hash: 08f1dfda4574284ab3c21666d1ee8c7d4, size: 1234} } } # 返回: jwt、buckets第二步上传文件内容Base64 编码需上传到返回的全部 bucket通常 2 个做冗余curl -X POST .../workers/assets/upload?base64true \ -H Authorization: Bearer $UPLOAD_JWT \ -F 08f1dfda4574284ab3c21666d1ee8c7d4BASE64_CONTENT # 返回: completion jwt第三步携带完成令牌部署 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资源隔离提示默认情况下 namespace 内资源是共享的若需按客户隔离应对 hash 加盐sha256(customerId fileContents).slice(0, 32)。Tags组织与批量操作每个 Worker 最多可打8 个 tag用于组织与批量过滤/删除# 设置 tags curl -X PUT .../tags -d [customer-123, pro, production] # 按 tag 过滤 curl .../scripts?tagsproduction%3Ayes # 按 tag 删除 curl -X DELETE .../scripts?tagscustomer-123%3Ayes常见 tag 模式customer-123客户 ID、free|pro|enterprise套餐、production|staging环境。注意 tag 过滤中的特殊字符必须 URL 编码如:→%3A并避免使用,、等特殊字符否则过滤会失效见 gotchas.md。删除 Worker 同样支持按 tag 批量执行。Bindings为用户 Worker 注入资源WfP 支持29 种绑定类型涵盖 KV、D1、R2、Durable Objects、Analytics Engine、Service、Assets、Queue、Vectorize、Hyperdrive、Workflow、AI、Browser 等见 bindings 文档。在部署客户 Worker 时通过 API metadata 声明原文档示例{ bindings: [ {type: kv_namespace, name: USER_KV, namespace_id: ...}, {type: r2_bucket, name: STORAGE, bucket_name: ...}, {type: d1, name: DB, id: ...} ] }更新时保留既有绑定若只想新增/替换部分绑定而不丢失已有配置使用keep_bindings声明需要保留的类型{ bindings: [{type: r2_bucket, name: STORAGE, bucket_name: new}], keep_bindings: [kv_namespace, d1] // 保留这些类型的既有绑定 }忘了加keep_bindings会导致更新时绑定丢失——这是 gotchas.md 中明确列出的高频事故。多租户资源隔离模式patterns.md为每个客户创建独立的 KV namespace / D1 数据库 / R2 bucket再通过绑定注入const bindings [{ type: kv_namespace, name: USER_KV, namespace_id: customer-${customerId}-kv }];完整的绑定类型参考含 wrangler.jsonc 写法见 bindings/configuration.md注意所有类型合计有64 个绑定的上限。绑定注入同样可配合 TypeScript SDK 的workersForPlatforms.dispatch.namespaces.scripts.update接口完成见 api.md。运维陷阱与限额速查高频错误与对策提炼自 gotchas.mdWorker not foundDISPATCHER.get获取不存在的 Worker 时抛出应捕获并返回 404CPU time limit exceeded客户 Worker 超限建议用 Analytics Engine 记录违规并返回 429同时考虑按套餐调整限额主机名路由异常改用*/*通配路由其在各种 DNS 代理配置下含 orange-to-orange均稳定工作更新后绑定丢失更新请求未携带keep_bindings务必显式声明tag 过滤失效特殊字符未 URL 编码避免,、ES 模块部署失败必须使用 multipart 表单上传、metadata 指定main_module、文件类型设为application/javascriptmodule静态资源上传失败hash 必须是 SHA-256 前 16 字节32 位 hex上传会话创建后 1 小时内完成上传、上传完成后 1 小时内完成部署二进制文件需 Base64 编码Outbound Worker 未拦截调用它不拦截 Durable Object 与 mTLS 绑定的 fetch需据此规划出网控制TCP 连接失败启用 outbound 后connect()API 被禁用只拦截 fetch需要 TCP 时移除 outbound 或改用代理模式API 限流账户级 1200 请求/5 分钟、IP 级 200 请求/秒应实现指数退避重试不支持灰度发布namespace 内 Worker 不支持 gradual deployments只能全量发布可通过 Dispatch Worker 内 feature flag / 按比例路由实现分段上线。平台限额速查表限额项数值说明每 namespace Worker 数无限普通 Workers 每账户 500 个每账户 namespace 数无限建议 production staging 各一每 Worker 最大 tag 数8用于过滤与组织Worker 模式Untrusted默认无request.cf除非 trusted缓存隔离按 Workeruntrustedtrusted 下共享需键前缀灰度部署不支持仅全量发布caches.default禁用untrusted使用带自定义键的 Cache APICPU 自定义限额最高到套餐上限Dispatch Worker 按调用下发子请求自定义限额最高到套餐上限按调用下发参考文档workers-for-platforms README架构与决策树API 操作部署、绑定、静态资源与路由多租户模式分级限额、路由、观测陷阱与限额清单Bindings 完整类型参考【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cloudflare Workers for Platforms 配置实战：Dispatch Namespace、隔离模式与自定义限额完全指南
Cloudflare Workers for Platforms 配置实战Dispatch Namespace、隔离模式与自定义限额完全指南【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本文是 Cloudflare Workers for PlatformsWfP多租户平台配置的完整实战指南围绕 dispatch namespace 的绑定配置、Worker 隔离模式切换、自定义 CPU/子请求限额、静态资源部署、Tags 批量管理以及 Bindings 注入展开。读完本文你将掌握如何通过 wrangler.jsonc 与 REST API 完成整套平台配置并理解 untrusted / trusted 两种隔离模式的取舍与底层行为差异。架构背景配置在整个四组件模型中的位置Workers for Platforms 专为运行客户代码的多租户平台设计——例如多租户 SaaS、AI 生成代码的沙箱执行、可编程边缘函数平台、网站搭建器静态 动态内容等场景。它不适用于只运行自己代码的普通 Workers 场景README。整个架构由 4 个组件构成而配置文档覆盖的是其中第 1 个组件及与之关联的运行约束Dispatch Namespace——容纳无限量客户 Worker 的容器默认 untrusted 隔离模式Dynamic Dispatch Worker——请求入口负责鉴权、限额、校验等平台逻辑User Workers——客户代码运行在隔离沙箱中通过 API 部署可挂载 KV/D1/R2/DO 等绑定Outbound Worker可选——拦截客户 Worker 的外部 fetch控制出网并记录子请求。请求流转链路为Request → Dispatch Worker → env.DISPATCHER.get(customer) → User Worker 执行 → (外部 fetch 经 Outbound Worker) → Response → Dispatch Worker → Client本指南中的每一项配置namespace 绑定、隔离模式、限额、静态资源、Tags、Bindings都在为这条链路提供服务下面逐一展开。Dispatch Namespace Binding 配置Dispatch Worker 通过名为DISPATCHER的绑定访问 namespace 中的任意客户 Worker。在wrangler.jsonc中声明如下原文档配置示例{ $schema: ./node_modules/wrangler/config-schema.json, dispatch_namespaces: [{ binding: DISPATCHER, namespace: production }] }配置要点$schema指向本地node_modules/wrangler/config-schema.json让编辑器与 CLI 获得配置校验与补全binding是 Dispatch Worker 代码中使用的绑定名绑定后即可通过env.DISPATCHER调用namespace指定绑定到的 namespace 名称。从仓库实践看最佳做法是每个环境一个 namespace如productionstaging各一个方便隔离与发布控制见 README 与 patterns。env.DISPATCHER的类型签名来自 api.md为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() 次数 }即在 Dispatch Worker 中env.DISPATCHER.get(workerName, {}, { limits, outbound })即可按客户动态下发限额与出网参数。Worker 隔离模式Untrusted 与 Trusted默认 Untrusted 模式namespace 中的 Worker 出于安全考虑默认运行在untrusted 模式具体表现为三条硬约束无法访问request.cf对象拿不到地理信息等请求上下文每个 Worker 拥有独立缓存namespace 内不共享缓存caches.default被禁用。这保证了即使某个客户代码被攻破也无法读取其他客户的数据或共享缓存。启用 Trusted Mode对于完全由你控制全部代码的内部平台可以显式开启 trusted 模式通过 REST API 修改 namespace 属性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}开启后需要特别注意的Caveatsnamespace 内 Worker 开始共享缓存必须用缓存键前缀隔离客户数据推荐格式customer-${id}:${key}request.cf对象变为可访问开启 trusted 模式后必须重新部署已有 Worker才能生效。何时使用 trusted内部平台、A/B 测试平台、需要地理位置geolocation数据的场景。凡是运行外部客户代码都应保持默认 untrusted。这一取舍在 README 决策树 中归纳为运行客户代码 → untrusted默认需要request.cf地理位置 → trusted内部平台且代码可控 → trusted 缓存键前缀追求最大隔离 → untrusted 每个客户独立资源。带 Outbound Worker 的配置当需要拦截客户 Worker 的外部 fetch 以控制出网时在dispatch_namespaces中补充outbound声明{ dispatch_namespaces: [{ binding: DISPATCHER, namespace: production, outbound: { service: outbound-worker, parameters: [customer_context] } }] }service指定出网拦截 Workerparameters声明在调用时透传给该 Worker 的参数名如customer_context。运行时在 Dispatch Worker 中通过dispatchOptions.outbound传入具体值const userWorker env.DISPATCHER.get( workerName, {}, { outbound: { customer_context: { customer_name: workerName, url: request.url } } } );Outbound Worker 内部通过env.customer_name等绑定拿到上下文可实现域名黑名单拦截、注入鉴权头等逻辑完整实现见 api.md。Wrangler 命令行管理 Dispatch Namespace配置完成后可用 wrangler 命令完成 namespace 的增删查改原文档命令清单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另外部署客户 Worker 到指定 namespace 的命令为见本文静态资源一节npx wrangler deploy --name customer-site --dispatch-namespace productionCustom Limits每次调用的 CPU 与子请求限额WfP 的核心能力之一是按调用动态控制客户代码的资源消耗。在 Dispatch Worker 中为单个用户 Worker 设置限额原文档示例const userWorker env.DISPATCHER.get( workerName, {}, { limits: { cpuMs: 10, // 单次调用最大 CPU 毫秒数 subRequests: 5 // 单次调用最大 fetch() 次数 } } );限额上界取决于你的 Workers 套餐计划额度见 gotchas.md 操作限额表可在限额内为不同客户档次设置不同值。限额违规处理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将客户计划存于 KV按 enterprise / pro / free 分别下发{ cpuMs, subRequests }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 });配合 Analytics Engine 将违规事件写为数据点即可对客户用量进行统计与告警env.ANALYTICS.writeDataPoint({ indexes: [customerName], blobs: [cpu_limit_exceeded], });部署静态资源WfP 支持随 Worker 一起部署 HTML/CSS/图片等静态资源有 CLI、Dashboard、REST API 三种途径。Wrangler 方式在wrangler.jsonc中声明资源目录与绑定{ name: customer-site, main: ./src/index.js, assets: { directory: ./public, binding: ASSETS } }然后部署到指定 namespacenpx wrangler deploy --name customer-site --dispatch-namespace productionDashboard 部署不熟悉 CLI 时的替代路径在 Dashboard 上传 Worker 文件通过--dispatch-namespace标志指定目标 namespacewrangler deploy --dispatch-namespace production或在wrangler.jsonc的dispatch_namespaces中预先配置。REST API 三步上传流程程序化部署走创建会话 → 上传文件 → 部署 Worker三步详见 api.md第一步创建上传会话提交资源清单hash 为 SHA-256 截断前 16 字节即 32 位十六进制字符curl -X POST .../scripts/$SCRIPT_NAME/assets-upload-session \ -H Authorization: Bearer $API_TOKEN \ -d { manifest: { /index.html: {hash: 08f1dfda4574284ab3c21666d1ee8c7d4, size: 1234} } } # 返回: jwt、buckets第二步上传文件内容Base64 编码需上传到返回的全部 bucket通常 2 个做冗余curl -X POST .../workers/assets/upload?base64true \ -H Authorization: Bearer $UPLOAD_JWT \ -F 08f1dfda4574284ab3c21666d1ee8c7d4BASE64_CONTENT # 返回: completion jwt第三步携带完成令牌部署 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资源隔离提示默认情况下 namespace 内资源是共享的若需按客户隔离应对 hash 加盐sha256(customerId fileContents).slice(0, 32)。Tags组织与批量操作每个 Worker 最多可打8 个 tag用于组织与批量过滤/删除# 设置 tags curl -X PUT .../tags -d [customer-123, pro, production] # 按 tag 过滤 curl .../scripts?tagsproduction%3Ayes # 按 tag 删除 curl -X DELETE .../scripts?tagscustomer-123%3Ayes常见 tag 模式customer-123客户 ID、free|pro|enterprise套餐、production|staging环境。注意 tag 过滤中的特殊字符必须 URL 编码如:→%3A并避免使用,、等特殊字符否则过滤会失效见 gotchas.md。删除 Worker 同样支持按 tag 批量执行。Bindings为用户 Worker 注入资源WfP 支持29 种绑定类型涵盖 KV、D1、R2、Durable Objects、Analytics Engine、Service、Assets、Queue、Vectorize、Hyperdrive、Workflow、AI、Browser 等见 bindings 文档。在部署客户 Worker 时通过 API metadata 声明原文档示例{ bindings: [ {type: kv_namespace, name: USER_KV, namespace_id: ...}, {type: r2_bucket, name: STORAGE, bucket_name: ...}, {type: d1, name: DB, id: ...} ] }更新时保留既有绑定若只想新增/替换部分绑定而不丢失已有配置使用keep_bindings声明需要保留的类型{ bindings: [{type: r2_bucket, name: STORAGE, bucket_name: new}], keep_bindings: [kv_namespace, d1] // 保留这些类型的既有绑定 }忘了加keep_bindings会导致更新时绑定丢失——这是 gotchas.md 中明确列出的高频事故。多租户资源隔离模式patterns.md为每个客户创建独立的 KV namespace / D1 数据库 / R2 bucket再通过绑定注入const bindings [{ type: kv_namespace, name: USER_KV, namespace_id: customer-${customerId}-kv }];完整的绑定类型参考含 wrangler.jsonc 写法见 bindings/configuration.md注意所有类型合计有64 个绑定的上限。绑定注入同样可配合 TypeScript SDK 的workersForPlatforms.dispatch.namespaces.scripts.update接口完成见 api.md。运维陷阱与限额速查高频错误与对策提炼自 gotchas.mdWorker not foundDISPATCHER.get获取不存在的 Worker 时抛出应捕获并返回 404CPU time limit exceeded客户 Worker 超限建议用 Analytics Engine 记录违规并返回 429同时考虑按套餐调整限额主机名路由异常改用*/*通配路由其在各种 DNS 代理配置下含 orange-to-orange均稳定工作更新后绑定丢失更新请求未携带keep_bindings务必显式声明tag 过滤失效特殊字符未 URL 编码避免,、ES 模块部署失败必须使用 multipart 表单上传、metadata 指定main_module、文件类型设为application/javascriptmodule静态资源上传失败hash 必须是 SHA-256 前 16 字节32 位 hex上传会话创建后 1 小时内完成上传、上传完成后 1 小时内完成部署二进制文件需 Base64 编码Outbound Worker 未拦截调用它不拦截 Durable Object 与 mTLS 绑定的 fetch需据此规划出网控制TCP 连接失败启用 outbound 后connect()API 被禁用只拦截 fetch需要 TCP 时移除 outbound 或改用代理模式API 限流账户级 1200 请求/5 分钟、IP 级 200 请求/秒应实现指数退避重试不支持灰度发布namespace 内 Worker 不支持 gradual deployments只能全量发布可通过 Dispatch Worker 内 feature flag / 按比例路由实现分段上线。平台限额速查表限额项数值说明每 namespace Worker 数无限普通 Workers 每账户 500 个每账户 namespace 数无限建议 production staging 各一每 Worker 最大 tag 数8用于过滤与组织Worker 模式Untrusted默认无request.cf除非 trusted缓存隔离按 Workeruntrustedtrusted 下共享需键前缀灰度部署不支持仅全量发布caches.default禁用untrusted使用带自定义键的 Cache APICPU 自定义限额最高到套餐上限Dispatch Worker 按调用下发子请求自定义限额最高到套餐上限按调用下发参考文档workers-for-platforms README架构与决策树API 操作部署、绑定、静态资源与路由多租户模式分级限额、路由、观测陷阱与限额清单Bindings 完整类型参考【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考