Cloudflare Workers 等 Deno Deploy 替代方案：价格对比与迁移指南

在 Deno Deploy 替代方案中，建议先评估 Cloudflare Workers：Deno 已将其指定为迁移目的地，并表示 Deploy 将继续运行 6 个月。网站只需迁移基于 Deno 的边缘逻辑，可以选 Netlify；以数据库为核心的 API，可以考虑 Supabase Edge Functions；围绕 Web 框架构建的应用适合 Vercel Functions；小型定时任务则可以交给 Val Town。如果应用用了 Deno KV，先确定存储替代方案，再决定函数部署在哪里。

本文价格与文档核验于 2026 年 10 月 12 日。比较依据是公开价格、运行时接口与行为约定，以及迁移所需的改造工作，未登录各平台进行部署测试。停服时间窗口来自 Deno 10 月 9 日的公告。

Cloudflare Workers 等 Deno Deploy 替代方案速览

选择迁移平台时，目标是在保留应用现有行为的同时，尽量减少后续需要维护的改动。调用外部数据库的 TypeScript 接口，与事务、定时任务和队列全都依赖 Deno Deploy 的应用，迁移难点完全不同。

套餐信息来源为 Cloudflare、Netlify、Supabase、Vercel、Val Town 及其计费 FAQ，以及 DigitalOcean VPS 价格页。这些只是起步价，不代表应用每月的总账单。

Deno 公告说了什么，迁移窗口该怎么理解？

Deno Deploy 将关闭，而 Deno 运行时有单独的维护期限。Ryan Dahl 在 2026 年 10 月 9 日的公告中写道：

Deno Deploy 将继续运行六个月，之后关闭。

同一份公告承诺，为迁往 Cloudflare Workers 的付费客户提供迁移支持。Deno 运行时还将继续按月发布更新一年，内容包括缺陷修复和安全更新；此后 Deno 将结束对该运行时的开发。运行时仍然开源。JavaScript 和 TypeScript 包注册服务 JSR 将继续运营，其基础设施会迁往 Cloudflare。阅读 Deno 公告。

Deno 给出的是时间窗口，没有指定具体停服日期。 不要据此编造截止日期，也不要把运行时较长的维护期限当作 Deploy 的额外使用时间。付费客户应利用迁移支持，同时规划应用与数据的迁移。

1. Cloudflare Workers：优先评估的迁移目的地

Cloudflare Workers 是托管请求处理程序和后台任务的平台。Deno 明确引导客户迁往这里，因此它最适合作为候选名单的起点。对于使用 TypeScript API、外部数据库和定时清理任务的创业者，主要工作是适配运行时接口和部署配置。围绕 Deno KV 构建的应用，则需要单独重新设计存储。选择 Workers 作为目标平台时，要为无法原样迁移的 Deno 专用部分明确预留改造成本。

适用场景： 希望使用托管基础设施的 API、Webhook、cron 任务、队列和网站。
主要优势： Deno 指定的迁移目的地，平台自身提供存储和调度服务。
价格： 提供 Workers Free；Workers Paid 每个账户最低 $5 USD/月；Enterprise 用量按合同计费。
免费试用： 可用长期提供的 Workers Free 套餐进行评估。
迁移工作量： 无状态处理程序为低至中等；KV 事务和队列任务需要重新设计时为高。

TypeScript 代码需要改哪些地方？

Workers 使用 workerd 运行时，并非 Deno 运行时，也不提供全局 Deno 命名空间。Request、Response、fetch 等标准 Web 接口有利于代码移植；Deno.serve、Deno.env、Deno.openKv 和 Deno.cron 则标出了需要替换的接口。Node.js 兼容性也只覆盖部分 API，因此开发时能成功导入一个包，并不能证明它依赖的运行时能力都能正常工作。Workers 运行时 API。

Wrangler 是 Cloudflare 的部署命令行工具。Deno 官方的 Wrangler 教程 介绍了如何继续使用 Deno 开发工具链：添加 npm:wrangler，生成 Workers 类型，导出包含 fetch 处理函数的模块；需要 Deno 模块解析时，通过 esbuild 配合 Deno 插件打包。用 Deno 构建上传产物，并不意味着部署后的 Worker 会成为 Deno 进程。

将密钥和资源访问迁入 bindings（绑定）。这些配置好的访问句柄，让 Worker 能连接数据库、队列或读取环境变量。除了应用文件，也要检查依赖：即使路由处理程序只调用 Web API，某个工具库内部仍可能访问文件系统。Cloudflare 绑定文档。

按实际行为匹配替代服务

关键在于分清 Workers KV 与 Deno KV。Workers KV 适合读多写少的场景，缓存读取可能返回旧数据。迁移库存预留、账户余额或原子唯一性检查时，不能因为名字都带 KV 就直接替换。Workers KV 工作原理。

D1 走的是 SQL 路线，需要把键前缀和二级索引转成经过设计的数据库结构。它的 batch API 会以事务方式执行语句，但不会自动还原 Deno 的乐观并发检查。Durable Objects 将状态与负责协调的计算实例放在一起；房间、账户等实体需要串行协调时，值得评估。D1 事务、Durable Objects。

定时任务可以使用 Cron Triggers，通过 scheduled 处理函数按 UTC 时间调度；需要延后处理的工作，则由 Queues 提供消息系统。调度决定何时开始，队列保存等待处理的工作，替换其中一个并不等于替换另一个。静态网站可使用 Workers Static Assets，将生成的文件与动态请求逻辑分开。

价格与执行限制怎么算？

Workers Free 包含每天 100,000 次请求和每次调用 10 ms CPU 时间。Paid 每月包含 1,000 万次请求和 3,000 万 CPU 毫秒；超出后，每增加 100 万次请求收取 $0.30，每增加 100 万 CPU 毫秒收取 $0.02。数据库、队列和其他产品用量也要单独计入预算。Workers 当前价格。

打包体积本身已不再是升级 Paid 的理由：Free 和 Paid 都允许解压后 64 MiB，内存仍为 128 MB。可以查看当前限制和我们的包体积与付费升级说明。Cloudflare 评测则进一步介绍了账户内各类产品如何配合使用。

1. 1

   盘点运行时依赖

   找出 Deno 命名空间调用、URL 导入、文件系统访问、密钥、KV 操作、定时计划和队列消费者。把可移植的业务逻辑与这些适配代码分开。

2. 2

   将入口改成 Worker 形式

   按 Deno 的 Wrangler 教程配置模块处理函数和生成的 Workers 类型；如果导入方式有要求，再设置支持 Deno 的自定义构建流程。改变处理函数的调用方式时，保持原有响应约定。

3. 3

   明确配置状态存储和触发器

   先选数据库，再导入记录。添加绑定，将定时计划映射到 Cron Triggers，并重写队列生产者和消费者。写清楚同一个任务再次投递时系统会如何处理。

4. 4

   切换流量前先演练

   使用本地测试数据和独立的目标环境，对比状态码、响应头、身份验证及状态变化。代码部署只是其中一个检查点；数据与后台任务也必须为同一次切换做好准备。

2. Netlify：适合带 Deno 边缘逻辑的网站

Netlify 是提供基于 Deno 的 Edge Functions 的网站部署平台，适合动态逻辑围绕入站请求展开的网站，例如本地化、身份验证检查、重定向或轻量个性化。让这部分逻辑与网站部署预览处于同一流程，可能比换一套基础设施模式更有价值。无状态边缘处理程序适合迁入；高度依赖队列的后端则需要拆分更多工作。如果产品本身就是网站，边缘逻辑只是为网站服务，可以选择 Netlify。Edge Functions 概览。

适用场景： 带有轻量 Deno 请求处理逻辑的静态网站和 Web 应用。
主要优势： Edge Functions 与网站一起部署，包含预览和回滚流程。
价格： Free 永久免费，$0；Personal $9/月；Pro $20/月，成员数量不限；Enterprise 定制报价。
免费试用： Free 每月限额 300 积分。
迁移工作量： 网站与无状态边缘逻辑为低至中等；需要拆分存储、定时任务和队列消费者时，工作量更高。

运行时熟悉，应用接口仍要适配

Edge Function 使用 Netlify 自己的处理函数和上下文。导入配置也需要检查：Netlify 文档使用独立的 import-map 文件，而不是 deno.json 内的 import map，并将 npm 包支持标为 beta。当前依赖解析建立在 Deno 配置之上的项目，需要专门处理这项迁移。Edge Functions API。

执行限制为每次请求 50 ms CPU 时间，响应头超时为 40 秒。等待远程服务与转换大型文档消耗的是不同额度。身份验证查询可能适合轻量边缘设计；CPU 密集处理则应另选执行方式。Edge Function 限制。

Deno KV、cron 和队列分别迁往哪里？

适合按键访问的内容可使用 Netlify Blobs；需要关系型数据和事务更新的应用，则可以选择其 Postgres 服务 Netlify Database。Blobs 可选强一致性读取，但仅有更强的读取一致性，无法复现 Deno KV 的多键原子操作 API。替代存储设计必须继续保证原有业务约束，例如不允许用户名重复。

Scheduled Functions 是 Netlify Functions 的一项独立功能。在 Edge Function 里写上 Deno.cron，不会自动获得托管调度。需要提取任务、配置计划，并单独检查它的运行时。如果原任务消费 Deno KV 队列，也必须明确持久化消息存储和消费者的去向；为函数配置定时执行，不会迁走队列中的消息。

对于运营内容网站、每小时执行一次同步任务的创业者，这样拆分通常可控：网站分发和个性化交给 Web 平台，同步任务则有自己的定时函数和持久化状态。如果应用主要由相互依赖的后台工作进程组成，这条路线的吸引力就会下降。

把积分用量和团队需求一起算进去

Personal 包含 1,000 积分/月。Pro 每月积分档位分别为 3,000 积分，$20、5,000 积分，$33、10,000 积分，$63、15,000 积分，$95 和 20,000 积分，$126。从 5,000 积分起的较高档位，允许将当月未用完的积分结转到下个账期；基础档不支持。Netlify 当前积分档位。

自动充值默认关闭。开启后，Personal 可花 $5 增加 500 积分，Pro 可花 $10 增加 1,500 积分。账户额度用尽且没有补充积分时，项目可能暂停，因此公开上线前既要决定如何部署，也要决定支出策略。这套现行积分套餐，不应与 Netlify 过去按席位计费的方案混为一谈。

3. Supabase Edge Functions：适合以数据库为核心的 API

Supabase Edge Functions 是运行在 Deno 兼容运行时上的 TypeScript 函数。如果这次迁移也打算把数据转入关系型数据库 Postgres，它就是很合适的选择。接收支付 Webhook、更新客户记录的订阅制应用，可以在这里找到自然的落点。熟悉的运行时减少了一类改动，数据库设计则成为主要工作。如果持久化应用数据决定了架构，优先考虑 Supabase。函数文档。

适用场景： 需要与 Postgres、身份验证和文件存储紧密配合的 Webhook 与 API。
主要优势： Deno 兼容函数与数据库平台集成。
价格： Free $0/月；Pro $25/月起；Team $599/月起；Enterprise 定制报价。
免费试用： Free 每个项目包含 500,000 次 Edge Function 调用和 500 MB 数据库。
迁移工作量： 兼容的处理程序为中等；需要将 Deno KV 改成关系型数据库结构并重写事务逻辑时为高。

不只搬接口，还要迁移数据模型

把 Deno KV 调用替换为 Postgres 访问。用户收藏项之类的键前缀，应转成可查询的数据关系；唯一性检查则变成数据库约束或事务。如果重要查询一开始就需要解码键字符串，就不要仅为让导入看起来省事，而保留一堆含义不透明的键。

例如，支付处理程序可能需要同时记录事件并更新用户权益。验收标准是重试不能让权益重复发放。新函数成功返回 HTTP 响应，并不能证明存储改造后仍满足这项业务约束。

Supabase 还提供 Cron，用于执行数据库任务或调用 Edge Function；以及基于 Postgres 的持久化消息服务 Queues。需要有计划地用这些服务替换 Deno.cron 注册逻辑，以及 Deno KV 的入队和消费代码。还要明确消息如何确认处理完成，以及失败任务何时、如何重新进入可重试状态。

运行时限制与完整起步账单

Edge Functions 允许 256 MB 内存和每次请求 2 秒 CPU 时间。worker 的实际存续时长上限，在 Free 为 150 秒，在付费套餐为 400 秒；但更长的存续时间不会增加 CPU 额度。这些是不同限制，不能混为一谈，用来判断后台任务能运行多久。函数限制。

Pro 和 Team 包含 200 万次函数调用，超出后每增加 100 万次收取 $2。Free 允许 2 个活跃项目，项目闲置 1 周后会暂停。付费套餐包含 $10/月的计算额度，可覆盖一个 Micro 实例。Supabase 价格。

Supabase 不太适合作为网站静态前端的迁移目的地。函数限制文档说明，提供 HTML 需要自定义域名，否则 text/html 响应会被改成 text/plain。前端托管应与 API 平台分别选择。

4. Vercel Functions：适合因 Web 框架而迁移的应用

Vercel Functions 是随 Web 部署提供的托管服务端函数，适合主要为了前端框架和发布流程而切换平台的应用。如果创业者本就在围绕 Vercel 支持的框架重组应用，把 API 路由一并迁入可能很合理。但对其他部分基本不变的 Deno 服务，这条迁移路径没那么直接。为了应用工作流选择 Vercel 时，也要明确规划运行时与存储改造。

适用场景： 以框架为中心、API 路由与前端一同组织的 Web 应用。
主要优势： 在统一的应用部署流程中提供服务端函数。
价格： Hobby $0/月；Pro $20/月；Enterprise 定制报价。
免费试用： Pro 提供试用；Hobby 限个人非商业用途。
迁移工作量： 运行时和路由适配为中等；存储及后台任务也需要替换时为高。

改写代码，还是保留社区运行时？

Vercel 将 Node.js 列为受支持的运行时，Deno 则通过社区运行时 vercel-deno 提供支持。两者意味着不同的维护选择。迁移时间紧迫时，应先评估社区集成的兼容性和维护责任，再决定是否让生产环境依赖它。另一条路线是将处理程序和依赖迁入框架所使用的受支持运行时。Vercel 运行时文档。

对于 Deno KV，需要选择数据库并替换 API。Vercel 的存储指南区分了用于文件的 Blob、用于配置的 Global Config，以及用于应用数据的 Marketplace 数据库。不能仅因为配置存储提供了看似方便的键值接口，就默认用它保存需要事务保障的客户记录。

Vercel Cron 替换的是调度计划，不会替你迁移 Deno.cron 的代码注册逻辑。Hobby 允许任务每天运行一次，调度精度为小时级；Pro 支持最短每分钟一次。仅凭调度限制，频繁同步的任务就已经无法选择 Hobby。Cron 用法与价格。

Vercel Queues 目前在所有套餐中以 beta 形式提供，支持持久化主题、自动重试和至少一次投递。因此它可以成为 Deno KV 队列任务的候选去向，但生产者、消费者和确认机制仍需改写。如果队列是履行客户订单的唯一通道，决策时必须考虑其 beta 状态。

能部署的人越多，费用也会变

Pro 平台费包含 1 个部署席位和每月 $20 用量额度。额外付费席位每个 $20/月；只读席位免费。超过额度的用量和付费附加功能另算。Pro 计费详情。

企业迁出 Deno Deploy 时，免费的 Hobby 价格不能作为生产预算。应从符合商业用途要求的套餐算起，再加入数据库和队列需求，避免看似便宜的迁移最终变成一串意料之外的独立账单。

5. Val Town：适合小型 API 和定时任务

Val Town 为小程序提供托管环境，内置 HTTP、邮件和 cron 触发器，很适合只承担一项明确工作的轻量服务。例如更新外部系统的 Webhook、供内部工具调用的 API，或定时生成摘要的任务。它使用 Deno 运行时，因此值得纳入迁移候选；但存储和触发器接口仍有差异。如果项目是一项小型自动化任务，而不是需要自行运营的平台，可以选择 Val Town。Val Town 文档。

适用场景： 小型 API、Webhook 处理程序、定时集成和内部工具。
主要优势： 托管代码，内置触发器与 SQLite 存储。
价格： Free $0；Pro $21/月，按年付费；Business $167/月起，按年付费；Enterprise 定制报价。厂商 FAQ 列出的月付订阅价格为 Pro $25、Business $200。
免费试用： Free 是长期套餐，不支持自定义域名和私有 val。
迁移工作量： 无状态工具为低；需要持久化的小型任务为中等；较大的有状态应用为高。

计费周期不能忽略：价格页选中年付时展示的价格，不能被当作可随时按月取消的同价订阅。Val Town FAQ提供了月付价格对照，也确认了其 Deno 运行时。

任务足够小，迁移才会简单

把处理程序放入 val，也就是 Val Town 带版本管理的应用容器，再将调用方式映射到 HTTP 或 cron 触发器。对于只调用外部 API 并发送摘要的任务，需要持久化的状态可能只有最后处理到哪条记录。与包含多个事务实体和队列消费者、面向客户的应用相比，这种状态更容易梳理。

适用时，可以用 Val Town 的每个 val 独立 SQLite 数据库替换 Deno KV，也可以保留外部数据库。将键查询和原子检查改写为数据库操作。不能让 Deno.openKv 继续指向即将退役的托管存储，却认为迁移已经完成。

对于队列任务，要在设计中明确待处理工作的保存方式。用 cron 定期扫描任务表是一种可能的应用设计，但任务领取、重试和去重都需要自行实现。这不会自动保留 Deno KV 队列的行为。

执行频率、源码隐私和时长决定套餐

Free 的 cron 最短间隔为 15 分钟，单次任务实际运行时长上限为 1 分钟。Pro 将间隔缩短到 1 分钟，单次时长上限提高到 10 分钟；价目卡还列出 10 个自定义域名和 2,000 个私有 val。当前价格与限制。

公开的每日摘要任务可能适合 Free。私有集成或需要更频繁轮询的任务，即便流量很小，也需要其他套餐。源码是否私有与接口访问权限还是两件事：源码私有，本身并不说明谁能调用 HTTP 接口。

触发方式简单的无状态工具，迁移工作量低；需要搬迁持久化任务状态时为中等；若试图在其中复现大型应用的运行时和数据架构，工作量则高。这些判断描述的是改造范围，不是所需工时。

6. 自托管 Deno：适合优先保留运行时行为的应用

在虚拟专用服务器（VPS）上运行 Deno，可以保留运行时，但托管责任由你承担。容器将运行时和应用打包，便于在选定的主机上运行。如果文件系统访问、Deno 专用 API 或常驻进程行为占据了移植工作的主要部分，就值得考虑这条路线。**保留运行时节省的复杂度，大于运维服务器新增的复杂度时，自托管才合适。**Deno 提供了官方 Docker 指南。

适用场景： 深度依赖 Deno，且负责人能管理服务器或容器部署的应用。
主要优势： 自行掌控运行时、文件系统和进程生命周期。
价格： 开源运行时本身没有托管套餐。以 DigitalOcean 为例，Basic Regular Droplet 的 512 MiB 内存规格为 $4.00/月；1 GiB 规格为 $6.00/月。
免费试用： DigitalOcean 提到促销额度，但价格页未提供长期免费的 Droplet 档位。
迁移工作量： 运行时改写较少，运维责任更多；托管数据仍需要导出、导入和恢复方案。

这些只是VPS 标价，不是适用于所有 Deno 应用的配置建议。决策还应计入备份存储、监控和运维时间。使用已有服务器或许能省去新的主机订阅，但维护工作仍然存在。

Deno KV 和 cron 在自托管后如何工作？

Deno KV 可以指定持久化的本地数据库路径，在 CLI 中底层使用 SQLite。相比迁往其他厂商的存储服务，这样能保留更多 KV API。但它不会自动复制托管记录、重建分布式托管能力，也不会让临时容器文件系统变成持久存储。需要导出数据、按计划导入、挂载持久化存储，并验证备份确实可以恢复。Deno KV 文档。

调度也有同样的区别。在 CLI 中，Deno.cron 将执行状态保存在内存里，每个进程各有一套独立任务。如果运行多个应用副本，就必须决定由哪个副本负责定时任务，或如何协调它们。API 调用没变，不等于保留了 Deploy 的托管调度服务。Deno cron 行为说明。

小型单服务器应用可能可以接受这些运维工作。但如果业务需要冗余基础设施，又没人愿意负责备份、补丁或恢复，看似低廉的 VPS 账单可能换来代价高昂的精力消耗。

workerd 和 celld 是另一条自托管路线

Cloudflare 公告将 workerd 和 celld 列为当前可用的自托管选项。它们采用 Workers 编程模型，因此适用于已按 Workers 方式完成移植的代码，不能承诺原样运行全部现有 Deno 代码。Cloudflare 也承认，独立 workerd 的 Durable Objects 实现存在单实例扩展方面的缺口，并介绍了将 celld 的工作成果和思路融入 workerd 的计划。Cloudflare 公告。

不要把它们当作带有某种虚构免费档位的新托管订阅来估价。预算来自你提供的基础设施和运维投入。对于面临迁移压力的团队，应评估现有能力，以及自己能执行的恢复方案；未来的整合工作不能替代眼下的决策。

自托管 Deno 可以作为过渡，但考虑到 Deno 已公布的支持窗口，运行时的长期维护安排同样重要。

按项目实际工作负载选择平台

当最难迁移的是状态而非代码时，平台选择就会改变。可以按已识别的改动来评估工作量：低，指只需适配处理程序或构建流程，外部状态不变；中等，涉及运行时接口或存储 API 改写；高，还包括事务重设计、队列任务转移或新增运维责任。即使应用很小，只要正确性依赖这些行为，迁移也可能很复杂。

不依赖 Deno 专用 API 的 TypeScript 函数，先看 Workers。 保持请求和响应约定，再适配入口与部署。如果函数主要修改网站请求，Netlify 更有吸引力；如果主要操作 Supabase 数据库，就更适合 Supabase。若迁移本就由周边框架驱动，Vercel 更占优势。在这些目的地中，无状态处理程序通常是工作量最低的迁移场景。

Deno KV 迁移，先确定存储模型。 读多写少的内容可能适合 Workers KV 或 Netlify Blobs。需要事务的记录应考虑 D1、Postgres，或其他能保证所需业务约束的数据库。协调需求可能适合 Durable Objects。小型工具也许只需 Val Town SQLite。自托管本地 KV 能保留更多代码，但数据持久性与恢复责任会转到你身上。在完成事务和索引盘点、确认范围更小之前，任何托管 KV 迁移都应至少按中等工作量规划。

cron 迁移，要比较实际执行规则。 每日报表与频繁轮询需要不同套餐。Workers Cron Triggers 是优先评估的托管路线；Val Town 适合小型任务；Supabase Cron 适合数据库维护；Netlify Scheduled Functions 适合网站相关任务。Vercel Hobby 每天执行的限制，使它不适合高频任务。重新注册计划工作不多，避免重叠执行产生重复副作用则未必简单。

队列迁移，要把积压消息和消费者一起搬。 Cloudflare Queues 和 Supabase Queues 是明确的目的地，Vercel Queues 则提供了 beta 选项。迁移范围包括消息标识、重试、确认机制，以及已经在等待处理的任务。单靠定时器无法替代队列。如果排队任务代表对付费客户的履约义务，就应按高工作量迁移处理。

静态网站先搬生成产物，再判断哪些服务端代码确实需要移植。 Workers Static Assets 和 Netlify 都是直接候选；如果网站框架能从 Vercel 的工作流中受益，也应将其列入名单。重定向、响应头、表单、身份验证和动态路由要分别检查。纯静态产物的迁移工作量，低于每次请求都需要渲染个性化响应的网站。

Deno KV 迁移，怎样保留原有业务行为？

代码部署与数据迁移的成功标准不同。代码能正确响应，部署才算成功；目标系统能保留支撑这些正确响应的数据记录和业务规则，数据迁移才算成功。

导出前，先盘点使用了哪些 KV 能力：带类型的复合键、前缀扫描、过期机制、二级索引、乐观版本检查、原子更新和变更监听。Deno 的 KV 指南说明，一组键承载的应用行为，可能比简单对象导出看起来多得多。

用户名索引就是一个例子。如果应用同时存储用户记录，以及用户名到用户的映射，复制这两类记录还不够。新的写入路径必须维持它们的关系，并拒绝冲突更新。同样，原来用于会话过期的时间戳，在目标系统中也需要明确的执行规则；只导入值却不保留相应行为，可能导致会话有效时间过长。

对于队列，应在源系统可提供信息的范围内，分别列出待处理、已完成和失败的任务。决定是先让旧消费者处理完积压再切换，还是带着可安全重放的标识转移任务。幂等性意味着重复执行任务，不会重复产生业务效果。它能避免收据任务重试时反复发送收据，也能防止重复的履约消息造成重复工作。

1. 1

   明确复制期间的写入边界

   备份源数据，并决定复制期间如何处理写入。小应用可以短暂停写；更复杂的同步方案则需要核对差异。不要让并发变更在导出与切换之间悄悄丢失。

2. 2

   同时验证记录与行为

   按实体类型对比记录数量、代表性数值和键编码。使用受控测试数据，检查重复提交、冲突更新、过期和记录缺失等情况。验收预期业务结果，不能只看新 API 是否返回成功。

3. 3

   同时切换流量与任务责任

   目标状态准备好后，才能重定向请求。停用或交接旧计划与消费者，避免两个平台执行同一项有副作用的操作。按计划重新配置密钥和 Webhook 目标地址。

4. 4

   持续观察，并保留可用的回滚路径

   切换后监控错误、失败任务和业务事件，保留源数据备份。如果目标系统已接受新写入，回滚就需要数据对账与同步方案，而不只是把 DNS 改回去。

下一次动手时，先为最难迁移的有状态操作列出依赖清单，并确定目标方案。优先移植这项操作，再完善其余迁移工作。它暴露的风险，会比再搬一个无状态健康检查接口更多。

这些方案是怎么选出来的？

筛选依据是 Deno Deploy 应用中的典型工作负载：HTTP 函数、持久化状态、定时任务、队列任务和静态产物。Cloudflare 排在首位，因为 Deno 将其指定为迁移目的地。Netlify、Supabase 和 Val Town 入选，是因为它们提供基于 Deno 的执行能力，且各有适合的应用场景；Vercel 的价值在于 Web 部署流程；自托管则提供运行时控制权。

价格与功能已于 2026 年 10 月 12 日对照厂商公开页面核验。工作量评级描述的是文档所列接口需要怎样改造，不是实测迁移耗时、负载测试结果，也不代表登录试用后的结论。通用云服务未纳入候选名单，因为增加更多供应商名称，并不能解决运行时、状态和任务责任这几个核心问题。

这次迁移有哪些选择要避开？

不要把 Workers KV 直接当作事务型 Deno KV 的替身。 只有读写行为符合数据需求时才选择它。便宜的存储费用无法弥补一致性假设被破坏的后果。

不要用 Netlify Edge Functions 承担 CPU 密集型后台处理。 边缘请求的执行额度是选型边界，不应寄希望于升级付费套餐就能改变执行模型。

不要用 Vercel Hobby 承载商业生产应用。 价格页限定它用于个人非商业用途。cron 限制也使它不适合作为高频任务的免费方案来比较。

源码必须私有时，不要选 Val Town Free。 先看套餐是否满足使用条件，再看流量大小。同样，不要默认用 Supabase Edge Functions 接替传统静态网站；前端托管需要单独选择。

没有明确恢复负责人，就不要自托管。 把进程跑起来只是相对容易的一步。必须有人能恢复数据、重启服务，并在故障后说清楚究竟由哪个调度器负责执行任务。

迁移前常见问题

Deno Deploy 什么时候关闭？

公告给出的是六个月的继续运营窗口，没有指定具体日期。应按这一窗口规划，不要拿更长的运行时维护期限来替代。

离开 Deno Deploy 后，还能继续用 Deno 吗？

可以。Netlify Edge Functions、Supabase Edge Functions 和 Val Town 提供基于 Deno 或兼容 Deno 的执行环境；VPS 或容器则让你自行运行 Deno。但各托管平台都有自己的 API 和限制。保留 Deno，并不会自动保留托管 KV 数据库、定时计划或队列。

Deno KV 能直接迁到 Cloudflare KV 吗？

前提是适配 API，并确认应用的一致性要求符合 Workers KV 的行为。Deno KV 的原子检查、事务、索引和变更监听都需要明确的替代方案。事务型记录应评估 D1 或其他数据库；需要按实体协调的状态，可考虑 Durable Objects。

哪种免费套餐能运行我的 cron 任务？

先核对执行频率、执行额度、源码隐私和商业用途要求。Val Town Free 的最短间隔为 15 分钟，单次运行上限为 1 分钟。Vercel Hobby 限每日任务及个人非商业用途。Workers Free 的 CPU 额度较紧；Netlify 和 Supabase 也有各自的共享套餐额度。调度器免费，不代表整个任务都能免费运行。