更新日志

通过 Workflows，您可以为每个步骤配置内置的重试行为。以前，您可以配置具有固定延迟时长（例如秒、分钟或小时）的步骤重试，以及诸如 constant、linear 或 exponential 之类的退避策略。

步骤重试现在支持动态延迟函数。您无需仅选择基本延迟和退避策略，而是可以向 retries.delay 传递一个函数，并根据失败的尝试和抛出的错误计算下一次延迟。

当重试需要取决于故障类型时，这非常有用。您的 Workflow 可能需要在遇到速率限制错误后等待更长时间，但在发生短暂的网络故障后能更快地进行重试。如果下游 API 在其错误消息中返回了 Retry-After 值，延迟函数也可以适应提供商的指导。

await step.do(
	"sync customer",
	{
		retries: {
			limit: 5,
			delay: ({ ctx, error }) => {
				if (error.message.includes("rate limit")) {
					return `${ctx.attempt * 30} seconds`;
				}

				return "10 seconds";
			},
		},
	},
	async () => {
		await syncCustomer();
	},
);

await step.do(
	"sync customer",
	{
		retries: {
			limit: 5,
			delay: ({ ctx, error }) => {
				if (error.message.includes("rate limit")) {
					return `${ctx.attempt * 30} seconds`;
				}

				return "10 seconds";
			},
		},
	},
	async () => {
		await syncCustomer();
	},
);

动态延迟函数可以返回一个持续时间字符串、一个数字或一个解析为持续时间的 Promise。使用它们可以添加自适应重试行为，而无需编写单独的队列或调度逻辑。有关更多信息，请参阅休眠和重试。

Workflows 定价现在包括按步骤计费。自最初的公开 Beta 版以来已启用请求和 CPU 时间计费，且不会发生变化。

步骤是 Workflow 执行的每个工作单元，包括诸如休眠或等待事件之类的步骤操作。

您可以使用 GraphQL Analytics API 查询 Workflows 分析，包括 Workflow 实例的 stepCount。

自 2026 年 8 月 10 日起（不早于该日期），Cloudflare 将开始对 Workers Paid 计划的步骤和存储使用进行计费。

存储定价自 Workflows 正式发布以来就已公布，且不会发生变化。存储以 GB-月为单位度量持久化的 Workflow 状态。

Workers Free 计划的开发者无需为超出包含数量的步骤或存储付费。

Cloudflare 在 2026 年 8 月 10 日之前不会对步骤和存储使用量进行计费。

在此更改生效之前，您可以在 Cloudflare 仪表板 ↗中查看 Workflows 使用情况。为了降低成本，可以考虑减少每个 Workflow 的步骤数量，或提高存储状态的内存效率。

有关完整详细信息，请参阅 Workflows 定价页面。

Workflows 使构建可靠的多步骤应用程序变得更加容易，这些应用程序能够在下游系统故障时恢复。回滚处理程序现在通过 ctx 对象接收正在回滚的步骤的原始步骤上下文。这包括 ctx.step.name、ctx.step.count、ctx.attempt 以及应用了默认值的步骤 config。

步骤配置包含用于该步骤的重试和超时设置，因此您可以根据这些字段自定义步骤恢复逻辑。

await step.do(
	"create charge",
	async () => {
		const charge = await createCharge();
		return { chargeId: charge.id };
	},
	{
		rollback: async ({ ctx, output, error }) => {
			// `output` 是被回滚步骤返回的值。
			const { chargeId } = output as { chargeId: string };
			await refundCharge(chargeId, {
				// `ctx` 是原始步骤上下文，包括步骤名称、计数、尝试次数和配置。
				reason: `${ctx.step.name}: ${error.message}`,
			});
		},
		rollbackConfig: {
			// `rollbackConfig` 控制回滚处理程序的重试和超时。
			retries: { limit: 3, delay: "30 seconds", backoff: "linear" },
			timeout: "5 minutes",
		},
	},
);

请参阅回滚选项了解更多信息。

Workflows 现已支持 saga 风格的回滚，允许您向每个 step.do() 添加补偿逻辑，以应对下游故障。如果实例失败，回滚处理程序将按照 step-start 顺序的逆序执行。

这对于涉及外部系统的多步骤操作非常有用，例如库存预留、付款授权、工单创建或基础设施配置。与其将所有清理逻辑编写在顶级 catch 中，不如将每个补偿操作放在其所撤销的步骤旁边。

回滚处理程序支持自己的重试和超时配置，Workflows 现在在实例状态响应中公开回滚结果。Workflows 分析还会发送回滚生命周期事件，使在调试生产工作流时更容易区分正向执行失败和回滚失败。

await step.do(
	"provision resource",
	async () => {
		const resource = await provisionResource();
		return { resourceId: resource.id };
	},
	{
		rollback: async ({ output }) => {
			const { resourceId } = output;
			await deleteResource(resourceId);
		},
		rollbackConfig: {
			retries: { limit: 3, delay: "15 seconds", backoff: "linear" },
			timeout: "2 minutes",
		},
	},
);

await step.do(
	"provision resource",
	async () => {
		const resource = await provisionResource();
		return { resourceId: resource.id };
	},
	{
		rollback: async ({ output }) => {
			const { resourceId } = output as { resourceId: string };
			await deleteResource(resourceId);
		},
		rollbackConfig: {
			retries: { limit: 3, delay: "15 seconds", backoff: "linear" },
			timeout: "2 minutes",
		},
	},
);

请参阅回滚选项了解更多信息。

您现在可以在 wrangler.jsonc 中直接将 cron 计划附加到 Workflow 绑定（binding）。每次计划运行都会自动创建一个新的 Workflow 实例，因此您无需定义单独的带有 scheduled 处理程序的 Worker 来按间隔触发您的 Workflow。

例如，您可以在同一个 Workflow 上配置每小时、每 15 分钟或工作日计划：

{
	"workflows": [
		{
			"name": "my-scheduled-workflow",
			"binding": "MY_WORKFLOW",
			"class_name": "MyScheduledWorkflow",
			"schedules": ["0 * * * *", "*/15 * * * *", "0 9 * * MON-FRI"],
		},
	],
}

Cron 工作负载获得 Workflows 的所有相同优势，包括内置重试、多步骤持久执行以及 Workflows 的可配置超时。

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

// 根据 wrangler.jsonc 中为 MY_WORKFLOW 绑定定义的每个 cron 计划自动运行。
export class MyScheduledWorkflow extends WorkflowEntrypoint<Env> {
	async run(event: WorkflowEvent, step: WorkflowStep) {
		const data = await step.do("fetch source data", async () => {
			return await fetchSourceData();
		});

		// 如果此步骤失败，则仅使用以下自定义逻辑重试此步骤
		await step.do(
			"process and store results",
			{
				retries: { limit: 5, delay: "30 seconds", backoff: "exponential" },
				timeout: "10 minutes",
			},
			async () => {
				await processAndStore(data);
			},
		);
	}
}

这使得构建定期计划的作业（例如数据库备份、发票生成、报告聚合和清理任务）变得更加容易，而无需配置单独的 Cron Trigger 入口点。

有关更多信息，请参阅触发 Workflows。