Node 的安静复仇：一个 Deno 老用户爬了回去
David Bushell 在 Hacker News 上分享了他从 Deno 迁回 Node.js 的经历，构建速度提升 15%。请来前端基础设施工程师林一鸣，聊聊 runtime 之争为什么最后总是输给'省心'。
这周 HN 上有个标题很抓马的帖子：《Friendship ended with Deno, now Node is my best friend》。作者 David Bushell 是资深前端开发者，也是 Deno 多年的忠实用户。他把自己的静态站点生成器从 Deno 迁回了 Node.js，还用了个很有画面感的词——"爬"回去。评论区很快分成两派：一派说"Deno 终于凉了"，另一派说"这只是个案，别过度解读"。我请来老朋友林一鸣——前端基础设施工程师，做过 Node 性能优化，也维护过几个开源 CLI 工具，runtime 这点事他门儿清。我们聊了聊这次迁移到底发生了什么，Deno 怎么了，以及选 runtime 这件事的本质。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 一鸣，先说说你的第一反应。一个 Deno 老用户公开说"我爬回 Node 了"，这事让你意外吗？
林一鸣： 说实话，不意外，甚至有点"终于来了"的感觉。Bushell 的文章我细读了，他做的事其实很朴素：把静态站点生成器从 Deno 搬到 Node v26，用 node:fs、node:path 替换 Deno 私有 API，用 Hono 的 Node 适配器替换 Deno.serve。结果构建快了 15%。没有黑魔法，就是一次老老实实的迁移。但这篇文章能上 HN 热门，说明它戳中了很多人的情绪——这几年在 Deno 和 Node 之间摇摆的人，比想象中多得多。
小听： 15% 这个数字，算多还是算少？
林一鸣： 得看语境。对静态站点生成这种 IO 密集型任务，15% 是实打实的体感提升，不是误差。但更有意思的是反过来的问题：为什么从 Deno 迁到 Node 会变快？Deno 当年可是打着"更快更现代"旗号出来的。答案是 Node 这几年悄悄补的课太多了——V8 升级、内置模块优化、启动速度改进。很多人对 Node 的印象还停留在"回调地狱、node_modules 黑洞"的年代，但 2026 年的 Node，已经不是那个 Node 了。
迁移没有黑魔法，只有一行行替换掉的 API。
小听： 原文里 Bushell 对 Deno 的批评挺直接的，说它创新停滞，还有技术问题。你觉得公允吗？
林一鸣： 一半一半吧。Deno 确实遇到了麻烦——这两年能明显感觉到它的 momentum 不如以前，团队也有变动。但"创新停滞"这个说法，我觉得要打个问号。Deno 2 其实做了不少实事，比如对 npm 生态的兼容。但问题在于，当 Node 也开始"借鉴"Deno 的好设计时，Deno 的差异化就被稀释了。权限模型？Node 现在也有实验性的权限控制。开箱即用的 TypeScript？Node 也在路上了。当对手把你的长处一个个学走，你还剩什么？这才是最扎心的。
小听： 评论区有条高赞说："开发者最终投票给的不是最酷的工具，而是最省心的工具。"你认同吗？
林一鸣： 太认同了，这句话值得打印出来贴墙上。Deno 出道时"默认安全、单文件可执行、URL 导入"这些特性确实惊艳——但那是给博客和推特看的惊艳。真正要交付项目时，你要的是：报错能搜到答案、依赖不会突然断、招来的人都会用。Node 的"无聊"恰恰是它最大的资产：API 稳定、文档齐全、生态里什么轮子都有。基础设施的美德就是无聊，越无聊越可靠。
小听： 那 Deno 是不是就没意义了？
林一鸣： 恰恰相反，Deno 的意义很大——它倒逼 Node 进步了。没有 Deno，Node 可能到现在还在那儿慢慢悠悠。技术史上这种"鲶鱼"角色太重要了：Deno 证明了 JS runtime 可以有更好的默认体验，Node 学过去了，用户受益了。只是鲶鱼自己不一定能活下来，这很残酷，但很常见。
鲶鱼的价值，在于搅动一池春水。
小听： 最后给还在纠结选哪个 runtime 的开发者一句建议？
林一鸣： 三句话。第一，做需要长期维护的项目，Node 依然是默认的稳妥选项，别为追新而追新。第二，被 Deno 某个特性吸引时，先查一下 Node 是不是已经有了等价方案——大概率有了。第三，工具链上 fnm + pnpm 这套组合值得一试，跟选哪个 runtime 无关，这是 Bushell 文章里我最想抄的作业。
一句话总结：选 runtime 和选对象有点像，别选最让你心动的，选最让你省心的。