Deno 加入 Cloudflare：Node.js 之父给运行时时代画上句号

2026 年 10 月 9 日，Ryan Dahl——Node.js 和 Deno 两代 JavaScript 运行时的缔造者——在 Deno 官方博客发了一篇短文，标题只有一句话：Deno is joining Cloudflare。整个 Deno 团队加入 Cloudflare，celld 与 workerd 合并，Deno 运行时进入为期一年的维护倒计时。这不是一次普通的并购，它标志着”做一个更好的 Node.js 运行时”这条路线被正式判了缓刑。

一、公告说了什么

Deno 侧公告的关键条款：

Cloudflare 侧由 Kenton Varda 联合署名，他花了大量篇幅回应一个长期存在的质疑：Cloudflare Workers 是不是故意做成不兼容来锁定用户？

二、为什么是 Cloudflare：从 IRC 服务器说起

Ryan Dahl 在 Cloudflare 联名博客里讲了一个很长的故事。2009 年他在柏林的一个仓库里用 500 行 JavaScript IRC 服务器演示 Node.js，核心洞察是：移除同步网络 I/O，让异步编程变得简单。但那个 demo 始终困扰他——单线程、单机，扩展到多机需要自己搭一堆基础设施。

他在 Deno 里改进了 JS 开发体验，但没有改变”开发者需要自己拼装运行时周边”这个根本问题。直到他读到 Cloudflare 的 Durable Objects 文档——一个带 SQLite 数据库的分布式单例，每个 DO 像一台独立寻址的小服务器，单线程执行、可处理 WebSocket、本地 SQLite 同步访问。用一个 DO 对应一个聊天频道，数据和连接就天然分片了。

他想要的是这个抽象的自托管分布式版本——这就是 celld 的由来：一个 Rust 写的二进制，唯一外部依赖是对象存储桶。

三、Kenton Varda 的坦诚承认

Cloudflare 工程总监 Kenton Varda 在联名博客里罕见地坦诚：

workerd 虽然是开源的（就是生产环境跑的那份代码），但它的 Durable Objects 只支持单实例模式，够本地测试，不能扩展。我们一直想修，但生产环境的 DO 路由”是一个怪物”——为数百个位置设计，依赖一堆外部服务和 SRE 团队运维。去年春天我自己试了一次，没做成。

这段话解释了为什么 Cloudflare 对 celld 的出现是高兴而不是警惕。社区有个流行理论说 Cloudflare 故意让 Workers 不兼容来制造锁定，celld 作为开源实现是”逃生舱”。Varda 反驳说：workerd 本来就是开源的，确实有客户用它迁走过，但更多客户因为它开源才敢签 Cloudflare。

celld 在 2026 年 8 月发布时，已经实现了对 Cloudflare 核心服务的兼容——Durable Objects/Cells、KV、Queues、D1、R2、Workflows、Cron Triggers、Static Assets 和 Dynamic Workers 全部标注”Supported”，只有 Containers 处于”Experimental”。这正是 Varda 所说的”完全兼容我们自己的实现，同时专注于自托管和可扩展”。

官方公布的性能数据也解释了为什么 Cloudflare 愿意收购而非竞争：单台 8GB 内存节点可驻留 2500 个 cell（每个 cell 仅占 0.47MB 内存），唤醒一个休眠 cell 约 4ms，无状态请求 p50/p99 为 0.2/0.3ms，单 worker 线程吞吐约 94k req/s。Varda 在文中承认，Cloudflare 自己的生产 DO 路由”是一个怪物”，根本不适合自托管场景——celld 恰好补上了这个缺口。

四、生态影响

这起收购对 JavaScript 运行时格局的影响：

1. Deno 运行时正式进入终点：一年后不再有官方开发，社区分叉是大概率事件，但能维持多久未知；
2. Deno Deploy 六个月后关闭：使用 Deno 托管服务的团队需要尽快迁移，Cloudflare 提供迁移支持但不保证无缝；
3. Workers 编程模型获得自托管路径：celld + workerd 合并后，开发者可以在自己的基础设施上跑 Workers/DO，这是 Cloudflare 一直想做但没做完的；
4. JSR 留在 Cloudflare 生态：JavaScript 包注册表继续运营，对 Deno 生态用户是缓冲；
5. Node.js 本身不受影响：Node.js 由 OpenJS 基金会治理，Deno 的命运不直接影响 Node。

五、口径与局限

公告中有几个需要冷静看待的点：

1. “一年维护期”的含义：一年后只做安全更新和 bug fix，不会有新特性。依赖 Deno 特有 API（如 Deno.serve 原生层、权限模型）的项目需要开始规划迁移；
2. “合并 celld 和 workerd”是目标不是现状：Varda 说”未来几个月会有更多公告”，具体合并后 workerd 的自托管 DO 能不能真的分布式可用，还需要等代码落地；
3. Deno Deploy 六个月关闭期很短：生产项目需要在半年内完成迁移；
4. “Deno 将继续开源，欢迎他人继续开发”：这是标准话术，社区维护的活跃度和持续性历来存疑。

六、客观分析

优势：

1. Workers 自托管终于有人做了：celld 的分布式 DO 设计正是 workerd 缺的那块；
2. Ryan Dahl 加入 Cloudflare 带来运行时工程经验：Cloudflare 自己承认 workerd 的生态和开发者体验没做好；
3. JSR 和 rusty_v8 有了长期归宿；
4. 对 Cloudflare 来说，这比从零招人做 celld 更快。

局限：

1. Deno 用户被牺牲了：一年倒计时意味着押注 Deno 的团队需要紧急迁移；
2. Workers 锁定问题并未消除：虽然 workerd 开源了，但 DO 的分布式自托管实现还没合并进来，当前生产环境仍然只能在 Cloudflare 网络上跑；
3. Deno 的商业化尝试失败了：从 Deno Deploy 到 Deno KV 到 Deno Subhosting，Deno 公司始终没找到独立盈利路径，最终被收编；
4. 对 Node.js 生态是间接利好：Deno 作为”Node 替代品”的叙事终结，意味着 Node.js 的竞争压力减少。

七、回顾：Deno 的八年挣扎

Ryan Dahl 2009 年创造 Node.js，2018 年在 Node 阵营之外发布 Deno——初衷是修复他认为 Node.js 在安全、模块设计和工具链上的根本缺陷。Deno 带来了默认安全沙箱、原生 TypeScript、ESM 优先、标准库重构等改进，但一个残酷的事实是：Node.js 的生态惯性太强了。Deno 花了大力气做 Node 兼容性层（npm 支持、node: 内建模块），代价是自己的差异化定位被模糊。

商业化路线上，Deno 从 Deno Deploy（Serverless 托管）到 Deno Subhosting（多租户部署平台）到 Deno KV，始终在和 Cloudflare Workers、Vercel Edge Functions、Netlify 正面竞争。Cloudflare 的全球网络规模和定价优势让独立创业公司很难在这个赛道取胜。最终 Ryan Dahl 自己也承认：问题不在运行时本身，而在”分布式计算、状态协调、数据存储和自动扩缩容”这些周边基础设施——而这恰好是 Cloudflare 的 Durable Objects 已经解决的问题。

八、谁该关注

• Deno 项目维护者和用户：现在就应该评估迁移到 Cloudflare Workers 或其他运行时的路径；
• 自托管 Workers/DO 的需求方：celld + workerd 合并后可以关注自托管进展；
• JavaScript 运行时观察者：这是”多运行时竞争”时代结束的信号之一——Bun、Deno、Node 的三足鼎立正在收缩。

参考来源

• Cloudflare 官方博客：Deno is joining Cloudflare
• Deno 官方博客：Deno is joining Cloudflare
• Ryan Dahl 此前关于 JavaScript Containers 的文章
• Koala 项目库条目