更新日志

Wrangler 配置文件中全新的声明式 exports 字段取代了用于管理 Durable Object 类生命周期的命令式 migrations 数组。您无需再编写带有唯一标签的有序迁移步骤列表，而是声明 Worker 导出的每个 Durable Object 类，Cloudflare 会将其与已部署的内容进行对比，以确定需要创建、重命名还是删除哪些 Durable Object 状态。

在使用旧版迁移时，将 ChatRoom 重命名为 Room 需要保留这两个标记的步骤：

{
	"migrations": [
		{ "tag": "v1", "new_sqlite_classes": ["ChatRoom"] },
		{
			"tag": "v2",
			"renamed_classes": [{ "from": "ChatRoom", "to": "Room" }],
		},
	],
}

而使用 exports，您只需将 Room 声明为当前类，并将 ChatRoom 标记为已重命名：

{
	"exports": {
		"ChatRoom": {
			"type": "durable-object",
			"state": "renamed",
			"renamed_to": "Room",
		},
		"Room": { "type": "durable-object", "storage": "sqlite" },
	},
}

每个条目都以类名作为键。state 字段承载生命周期（默认为 created——活动类——以及墓碑（tombstone）状态 deleted、renamed、transferred，和用于跨 Worker 传输的接收状态 expecting-transfer）。

与旧版 migrations 数组相比的关键改进：

• 无需迁移标签。 当前的 exports 映射是唯一的真实数据源——无需维护 v1、v2、v3 条目的历史链。
• 结构化的部署输出。 Wrangler 会在创建、更新、删除、重命名或传输 Durable Object 类时进行报告。它还会识别可安全删除的陈旧配置条目。没有更改或通知的部署不会打印此输出。
• 零停机重命名和传输模式是一等公民。 墓碑（Tombstones）可以与代码中仍然存在的源类共存，从而实现 三次部署重命名 和 四次部署跨 Worker 传输，在滚动部署期间不会出现运行时错误。
• 跨 Worker 安全性。 当您删除或重命名类时，Cloudflare 会列出您账户中其绑定（binding）仍引用该命名空间的其他所有 Worker，以便您在更改生效前重新部署它们。

使用旧版 migrations 数组的现有 Workers 仍可照常工作，无需任何更改。要过渡到 exports，请参阅迁移指南。在单个 Worker 中，exports 和 migrations 是互斥的。

欲了解完整的参考信息，请参阅 Durable Object 类导出。