限制

¹ 如果达到此限制，请考虑使用 Workers for Platforms。

请求体大小限制取决于您的 Cloudflare 账户套餐，而非 Workers 套餐。超出这些限制的请求将返回 413 Request entity too large 错误。

Enterprise 客户可联系其账户团队或 Cloudflare Support 以获取更高的请求体限制。

Cloudflare 不强制执行响应体大小限制。CDN 缓存限制 适用：Free、Pro 和 Business 套餐为 512 MB，Enterprise 为 5 GB。

CPU 时间衡量 CPU 执行 Worker 代码所花费的时间。等待网络请求（例如 fetch() 调用、KV 读取或数据库查询）不会计入 CPU 时间。

大多数 Worker 消耗的 CPU 时间非常少。平均每个 Worker 每次请求约使用 2.2 ms。处理身份验证、服务端渲染或解析大型负载等较重的工作负载通常使用 10-20 ms。

每个 isolate 都有一些内置灵活性，以应对 Worker 偶尔超过配置限制的情况。如果你的 Worker 开始持续达到限制，其执行将根据配置的限制被终止。

当 Worker 超出其 CPU 时间限制时，Cloudflare 会向客户端返回 Error 1102，消息为 Worker exceeded resource limits。在仪表板中，这显示在 Metrics（指标） > Errors（错误） > Invocation Statuses（调用状态） 下的 Exceeded CPU Time Limits。在分析和 Logpush 中，调用结果为 exceededCpu。

要解决 CPU 时间限制错误：

1. 提高 CPU 时间限制 — 在 Workers Paid 套餐上，您可以将限制从默认的 30 秒提高到 5 分钟（300,000 ms）。在 Wrangler 配置或仪表板中设置。
2. 优化代码 — 使用 DevTools CPU 分析 识别代码中 CPU 密集的部分。
3. 卸载工作 — 将昂贵的计算移至 Durable Objects，或在多个请求中分块处理数据。

在 Workers Paid 套餐上，您可以将最大 CPU 时间从默认的 30 秒提高到 5 分钟（300,000 ms）。

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // default is 30000 (30 seconds)
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

您也可以在仪表板中更改：前往 Workers & Pages > 选择您的 Worker > Settings（设置） > 调整 CPU 时间限制。

• Workers Logs — CPU 时间和 wall time 显示在调用日志中。
• Tail Workers / Logpush — CPU 时间和 wall time 显示在 Workers Trace Events 对象 的顶层。
• DevTools — 在本地使用 DevTools CPU 分析 识别代码中 CPU 密集的部分。

每个 isolate 最多可消耗 128 MB 内存，包括 JavaScript 堆和 WebAssembly 分配。此限制按 isolate 计算，而非按调用计算。单个 isolate 可以处理许多并发请求。

当 isolate 超过 128 MB 时，Workers 运行时会允许进行中的请求完成，并为后续请求创建新的 isolate。在极高负载下，运行时可能会取消某些传入请求以维持稳定性。

当 Worker 超出其内存限制时，Cloudflare 会向客户端返回 Error 1102，消息为 Worker exceeded resource limits。在仪表板中，这显示在 Metrics（指标） > Errors（错误） > Invocation Statuses（调用状态） 下的 Exceeded Memory。在分析和 Logpush 中，调用结果为 exceededMemory。

当您尝试缓冲超出限制的响应体时，还可能会看到运行时错误 Memory limit would be exceeded before EOF。

要解决内存限制错误：

1. 流式传输请求和响应体 — 使用 TransformStream 或 node:stream 代替在内存中缓冲整个负载。
2. 避免大型内存对象 — 将大型数据存储在 KV、R2 或 D1 中，而不是保存在 Worker 内存中。
3. 分析内存使用情况 — 在本地使用 DevTools 内存分析 识别泄漏和高内存分配。

要在仪表板中查看内存错误：

1. 前往 Workers & Pages。

   Go to Workers & Pages ↗

2. 选择要调查的 Worker。

3. 在 Metrics（指标） 下，选择 Errors（错误） > Invocation Statuses（调用状态），查看 Exceeded Memory（超出内存）。

持续时间衡量 Worker 调用从开始到结束的挂钟时间。

HTTP 触发的 Worker 没有严格的持续时间限制。只要客户端保持连接，Worker 就可以继续处理、发出子请求并流式传输响应体。当客户端断开连接或响应完成时，与该请求关联的任务可能会被取消。使用 ctx.waitUntil() 在返回响应后执行工作。waitUntil() 可以在响应发送或客户端断开连接后延长执行最多 30 秒。

Workers 在 Cloudflare 全球网络上自动扩展。每秒请求数没有一般性限制。

Workers Free 套餐的账户每日请求限制为 100,000 次，在 UTC 午夜重置。当 Worker 超出此限制时，Cloudflare 返回 Error 1027。

您可以通过切换相应的路由来配置失败模式。

子请求是 Worker 使用 Fetch API 发出的任何请求，或对 R2、KV 或 D1 等 Cloudflare 服务的请求。

重定向链中的每个子请求都计入此限制。子请求总数可能超过代码中 fetch() 调用的次数。您可以使用 Wrangler 配置文件中的 limits 配置 更改每个 Worker 的子请求限制。

单个子请求没有设定的时间限制。只要客户端保持连接，Worker 就可以继续发出子请求。当客户端断开连接或响应完成时，未完成的工作可能会被取消，除非将其传递给 ctx.waitUntil()，后者可以延长执行最多 30 秒。

使用 Service Bindings 从一个 Worker 向账户上的另一个 Worker 发送请求，而无需经过 Internet。

使用全局 fetch() 在没有 service bindings 的情况下调用同一 zone 上的另一个 Worker 会失败。Workers 接受发送到 Custom Domain 的请求。

每个 Worker 调用最多可以同时有六个连接等待响应头。在建立初始连接且服务器尚未响应时，以下 API 调用计入此限制：

• Fetch API 的 fetch() 方法
• Workers KV namespace 对象 的 get()、put()、list() 和 delete() 方法
• Cache 对象 的 put()、match() 和 delete() 方法
• R2 的 list()、get()、put()、delete() 和 head() 方法
• Queues 的 send() 和 sendBatch() 方法
• 使用 connect() API 打开 TCP 套接字

出站 WebSocket 连接也计入此限制。

一旦连接的响应头到达，它就不再计入六个连接的限制。这意味着 Worker 可以同时打开许多连接，只要同时处于初始"等待响应头"阶段的连接不超过六个。如果在六个连接已在等待响应头时尝试第七个连接，它将被排队，直到现有连接之一收到响应头。

如果您使用 fetch() 但不需要响应体，调用 response.body.cancel() 仍然是释放内存的好习惯：

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

较大的 Worker bundle 可能会影响启动时间。要检查压缩后的 bundle 大小：

wrangler deploy --outdir bundled/ --dry-run

# Output will resemble the below:
Total Upload: 259.61 KiB / gzip: 47.23 KiB

要减小 Worker 大小：

• 移除不必要的依赖项和包。
• 将配置文件、静态资产和二进制数据存储在 KV、R2、D1 或 Workers Static Assets 中，而不是打包它们。
• 使用 Service bindings 将功能拆分到多个 Worker。

Worker 必须在 1 秒内解析并执行其全局作用域（处理器之外的全局代码）。较大的 bundle 和全局作用域中的昂贵初始化代码会增加启动时间。

当平台因 Worker 超出启动时间限制而拒绝部署时，验证会返回错误 Script startup exceeded CPU time limit（错误代码 10021）。Wrangler 会自动生成 CPU profile，您可以导入 Chrome DevTools 或在 VS Code 中打开。有关更多详细信息，请参阅 wrangler check startup。

要测量启动时间，运行 npx wrangler@latest deploy 或 npx wrangler@latest versions upload。Wrangler 会在输出中报告 startup_time_ms。

要减少启动时间，避免在全局作用域中进行昂贵的工作。将初始化逻辑移至处理器或构建时。例如，在顶层生成或消费大型 schema 是超出此限制的常见原因。

如果您需要超过 500 个 Worker，请考虑使用 Workers for Platforms。

当您使用 --remote 标志运行远程开发会话时，Cloudflare 对每个 zone 强制执行 50 条路由的限制。Cloudflare 仪表板中的 Quick Editor 也使用 wrangler dev --remote，因此适用相同的限制。

如果您的 zone 有超过 50 条路由，在删除路由使其低于限制之前，您无法运行远程会话。

如果您需要每个 Worker 超过 1,000 条路由或 1,000 个路由 zone，请考虑使用 Workers for Platforms。如果您需要每个 zone 超过 100 个 custom domains，请考虑使用通配符路由。

每个请求的调用次数是指每次请求中 put()、match() 或 delete() Cache API 调用的次数。这与子请求（fetch()）共享相同的配额。

此限制涵盖通过 console.log() 语句、异常、请求元数据和头为单个请求发出的所有数据。超出此限制后，系统不会在该请求的日志、tail logs 或 Tail Workers 中记录额外的上下文。

有关发送到 Logpush 目标的字段限制，请参阅 Workers Trace Event Logpush 文档。

有关使用 Image Resizing 与 Workers 时适用的限制，请参阅 Image Resizing 文档。

如果您的 Worker 在 Unbound 套餐上，限制与 Workers Paid 套餐一致。

如果您的 Worker 在 Bundled 套餐上，限制与 Workers Paid 套餐一致，但有以下例外：

Bundled 套餐 Worker 对 Cron Triggers、Durable Object Alarms 或 Queue Consumers 没有持续时间限制。

挂钟时间（也称为 wall-clock time）是从调用开始到结束的总经过时间，包括等待网络请求、I/O 和其他异步操作所花费的时间。这与 CPU 时间不同，后者仅衡量 CPU 主动执行代码所花费的时间。

下表总结了开发者平台上不同类型 Worker 调用的挂钟时间限制：

• KV 限制
• Durable Object 限制
• Queues 限制
• Workers 错误参考