Deno 一年后停止开发：Cloudflare「收购」背后，Node 赢了运行时战争
Cloudflare 收购 Deno 的消息背后藏着关键细节：Deno runtime 一年后停止开发，Deploy 半年后关停。访谈拆解 HN 对「收购式招安」的争论、迁移的现实疼痛，以及 celld 与 workerd 合并这场真正的赌注。
这周 JS 世界最大的新闻：Deno 官方博客宣布，整个 Deno 团队加入 Cloudflare。HN 上五百多条评论，吵的却不是"收购"本身——大家吵的是这个词用得对不对：Deno runtime 只再维护一年，之后停止开发；Deno Deploy 半年后关停，用户得迁到 Cloudflare Workers。这哪是收购，分明是"招安"。我请来老朋友林拓——边缘计算工程师，之前在 Deno Deploy 上跑过生产项目，现在正把东西往 Workers 上搬，两边他都熟。我们聊了聊这场"收购"到底买了什么、被留下的人怎么办，以及 Ryan Dahl 真正想下的那盘棋。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 林拓，先问最扎眼的。Deno 博客里把"runtime 再维护一年、之后停止开发"这句藏在后半段，HN 有人直接开喷：Cloudflare 那边的官宣干脆提都没提。这算是信息披露事故吗？
林拓： 算，而且是故意的温柔。你看两边的措辞：Deno 说"我们决定把未来的开发投入到共同平台，而不是继续开发一个独立的 runtime 和托管服务"——翻译过来就是，Deno 这个产品线判了死缓，一年。Cloudflare 那边只谈 celld 和 workerd 的美好未来，对 Deno 的结局只字不提。评论区那句说得最准：这不是 acquisition，这是 acqui-hire——买的是人，不是产品。
小听： 评论区确实有人问：既然要关掉，为什么还要"收购"？直接挖人不就行了，何必背这一身骂名？
林拓： 因为要买的不只是人，是这帮人手里那套东西的"合法继承权"。Deno 团队这几年真正值钱的产出已经不是 Deno runtime 了，是 celld——一套从第一天就按分布式来设计的编程模型，跑在 Cloudflare Workers 的编程模型之上。Cloudflare 要的是这套思想和写出它的人，一起并进 workerd。直接挖人，你得到的是简历；整体"收购"，你得到的是路线图、代码归属和对外叙事。骂名是真骂名，但比起让这套东西流落到竞争对手手里，值。
小听： 另一条高赞扎心评论：Bun 刚被 Anthropic 收走，现在 Deno 也没了，一年之内两个 Node 替代品全被收编，"I guess bun won"——但赢的好像也不是 Bun，是 Node。
林拓： 对，赢的是"不用选"。Deno 当年最大的赌注是跟 node_modules 决裂，搞 URL import、搞权限模型，姿态非常漂亮。但生态是路径依赖的，最后 Deno 不得不回头补 Node 兼容——一个产品开始"既要又要"，就是认输的开始。Bun 走的是另一条路：先做到"比 Node 更快的 Node"，兼容性拉满再谈理想。评论区有人总结得到位：Deno 输不是输在技术，是输在它想同时教育市场和讨好市场。Node 什么都不用做，躺着就赢了，因为所有人都已经在那了。
收购的是团队，告别的是产品。
小听： 聊点现实的。Deno Deploy 只给六个月，之后关停，付费用户 Cloudflare 说会帮迁到 Workers。评论区已经有人在喊"今晚就开始迁"。你自己就在搬，疼在哪？
林拓： 疼在"六个月"听起来长，实际很短。Deploy 和 Workers 看似都是"边缘跑 JS"，但 KV、队列、定时任务这些周边的 API 形状不一样，鉴权和环境变量的管理方式也不一样。最疼的是心智：当年选 Deno Deploy 的人，很多是冲着"一个团队、一个账单、一套心智模型"去的——runtime、部署、存储全包。现在这套全包散了，你得重新拼。这也是为什么评论区有人说"早知道就守着老而可靠的"：追新东西的风险，平时是抽象的，这时候就具象化了。
小听： 还有个连锁反应我没想到：有人提到 yt-dlp 把 Deno 当作首选的 JS runtime，拿来替代自己手写的 JS 解释器。Deno 停更，这种下游项目怎么办？
林拓： 这就是"基础设施诅咒"：你做得越底层、越好用，被依赖得越深，死的时候动静越大。好消息是 Deno 保持开源，理论上可以有人接盘继续维护；坏消息是评论区已经有人把话说透了——"除非有人接手，否则就是没人维护了"。开源代码不会消失，但"有人修安全漏洞"这个承诺会消失。对 yt-dlp 这种项目，短期切到 Node 或 QuickJS 都能跑，长期看的是谁愿意接这个维护担子。Deno 的遗产大概率是"思想被 workerd 吸收"，而不是"Deno 这个二进制继续活着"。
小听： 那 Cloudflare 到底图什么？评论区反复问这个问题，直到 Kenton Varda（Workers 的创造者）亲自下场回帖：Ryan 他们要把 celld 和 workerd 合并，做成"第一个真正一流的、开源可自托管的 Workers runtime"。这话你信几分？
林拓： 信七分，因为这是 Cloudflare 唯一缺的那块拼图。你看 Deno 博客里 Ryan 自己写的逻辑链：Deno → Deno Deploy → celld，一路都在回答"怎么让分布式应用从第一天就简单"。而 celld 现在最激动人心的应用场景，博客里写得明明白白：agent harnesses——便宜的 serverless 执行、持久化状态、WebSocket、高层 JS 接口，全是 Durable Objects 的拿手好戏。Cloudflare 在赌：下一代应用是 agent，而 agent 需要一种"默认就是分布式的"编程模型。他们买 Deno 团队，就是买这张船票。Ryan 在博客末尾留了个邮箱，喊"在大规模跑 agent、想跑在自己基础设施上的人来找我"——收购公告写成招聘广告，这很 Ryan。
运行时的战争结束了，基础设施的战争才刚开始。
小听： 最后一问，给还在选型的人一句话：从 Deno 这五年里，能搬走的最大教训是什么？
林拓： 两句。第一，选 runtime 别只看 DX，看"谁为它的十年负责"。Deno 的 DX 当年是最好的，VSCode 插件、开箱即用的 TypeScript、单文件可执行，全是好东西，但商业公司撑不起免费的理想主义，最后账单总会有人付。第二，关注"思想去哪了"，而不是"产品去哪了"。Deno 会死，但它证明过的东西——权限默认收紧、URL 优先的模块、开箱即用的工具链——已经渗进 Node 和 Bun 里了。现在它的分布式编程思想要渗进 workerd。对开发者来说，真正要押注的从来不是某个二进制，而是它验证过的那套思想会活在哪个生态里。这次，答案是 Cloudflare 的网络。
Deno 的故事有个黑色幽默的结尾：当年它举着"Node 的修正版"大旗出发，五年后，它最大的遗产是帮 Cloudflare 把 Workers 变成"默认的分布式编程模型"。运行时战争的终局不是谁取代了 Node，而是"运行时"这个概念本身被重写了——以后大家争的不是谁跑 JS 更快，是谁定义 agent 时代的执行层。本文观点仅代表访谈角色设定，原始讨论见参考链接。