限制

编写、部署和运行 Workflows 适用的限制详见下文。

许多限制继承自 Workers 脚本，如 Workers 限制 文档所述。

在 JavaScript Workflows 中，如果需要持久化步骤的大型二进制输出，请返回 ReadableStream<Uint8Array>。流式输出仍计入每实例存储限制，因此对于非常大或长期存在的工件，请考虑存储在外部存储（如 R2）中并在适当时返回引用。

处于 waiting 状态的实例——通过 step.sleep 休眠、等待重试或通过 step.waitForEvent 等待事件——不计入并发限制。这意味着你可以同时有数百万个休眠或等待事件的 Workflow 实例，因为只有 actively running 的实例计入 10,000 并发实例限制。 但是，如果有 10,000 个并发实例 actively 运行，处于 waiting 状态的实例将排队而不是立即恢复。 当实例从 running 转换为 waiting 时，其他 queued 实例将被调度（通常是最旧的排队实例，尽力而为）。如果等待时长很短，此状态转换可能不会发生。

例如，考虑一个执行一些工作、等待 30 天然后继续更多工作的 Workflow：

import {
	WorkflowEntrypoint,
	WorkflowStep,
	WorkflowEvent,
} from "cloudflare:workers";

type Env = {
	MY_WORKFLOW: Workflow;
};

export class MyWorkflow extends WorkflowEntrypoint<Env> {
	async run(event: WorkflowEvent<unknown>, step: WorkflowStep) {
		await step.do("initial work", async () => {
			let resp = await fetch("https://api.cloudflare.com/client/v4/ips");
			return await resp.json<any>();
		});

		await step.sleep("wait 30 days", "30 days");

		await step.do(
			"make a call to write that could maybe, just might, fail",
			{
				retries: {
					limit: 5,
					delay: "5 seconds",
					backoff: "exponential",
				},
				timeout: "15 minutes",
			},
			async () => {
				if (Math.random() > 0.5) {
					throw new Error("API call to $STORAGE_SYSTEM failed");
				}
			},
		);
	}
}

给定 Workflow 实例等待 30 天时，它将转换为 waiting 状态，允许其他 queued 实例在达到并发限制时运行。

在 Workers Paid 上，由 schedules 创建的 Workflow 实例每次 cron 触发可运行最多一小时，而不消耗 Workflow 并发槽位。

使用该预算后，实例让出并进入正常并发队列。当并发槽位可用时恢复。实例不会因使用此 cron 并发预算而失败、超时或终止。

以下限制适用于 Workflow schedules：

每个 Workflow 实例默认支持 10,000 步骤，但可以在 Wrangler 配置中提高至 25,000 步骤。请参阅 Workflow 步骤限制 了解更多信息。

Workflows 是 Worker 脚本，与任何 Workers 共享相同的每次调用 CPU 限制。请注意，CPU 时间是 active 处理时间：不包括等待网络请求、存储调用或其他 general I/O 的时间，这些不计入 CPU 时间或 Workflows 计算消耗。

如果 Workflow 超过 CPU 时间限制，将抛出以下错误：

Error: Worker exceeded CPU time limit.

这将在 wrangler tail 结果中显示为 exceededCpu，在 Workers 指标 中显示为 exceededResources。

默认情况下，每个 Workflow 调用的最大 CPU 时间为 30 秒，但可以通过在 Wrangler 配置中设置 limits.cpu_ms 为与 Workflow 定义关联的所有调用提高：

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

要了解更多关于 CPU 时间和限制的信息，请参阅 Workers 文档。

子请求是 Workflow 使用 Fetch API 向 Internet 资源发出的任何请求，或对 R2、KV 或 D1 等其他 Cloudflare 服务的请求。由于 Workflows 长时间运行且经常向外部服务或 Cloudflare API 发出许多调用，它们可能超过默认子请求限制。

如果 Workflow 超过子请求限制，将抛出以下错误：

Error: Too many subrequests.

这将在 Workers 指标 中显示为 exceededResources，在 wrangler tail 结果中显示为 exception。

默认情况下，Workers Paid 计划上每个 Workflow 实例的最大子请求数为 10,000，但可以通过在 Wrangler 配置中设置 limits.subrequests 提高至 1000 万：

{
	// ...rest of your configuration...
	"limits": {
		"subrequests": 10000000, // 10 million (maximum)
	},
	// ...rest of your configuration...
}

[limits]
subrequests = 10_000_000

Free 计划上的 Workers 每次调用仍限制为 50 个外部子请求和 1,000 个对 Cloudflare 服务的子请求。

要了解更多关于子请求限制的信息，请参阅 Workers 文档。

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

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