Cloudflare 接连迎来 Astro、VoidZero 与 Deno 团队之后：前端工具链进入“收编时代”，开发者该如何自处

本文是个人观点。事实尽量引用公开的一手来源；官方承诺与计划、作者判断，以及未能独立核实的二手说法会分别标明，具体出处见文中引用。

引子：一个周五晚上的倒计时

2026 年 10 月 9 日，周五。Ryan Dahl 在 Deno 官方博客上宣布，整个 Deno 团队加入 Cloudflare。我先是在推上刷到标题，第一反应是：又一个 acqui-hire。点进去读完，却愣了一下。Deno 运行时再给一年的每月修复和安全更新，之后官方停止开发；Deno Deploy 再跑六个月，然后关停（Deno 官方博客）。

这不是“加入”，更像是谢幕。

Ryan Dahl 是 Node.js 的作者。2018 年，他做 Deno，是想解决自己当年在 Node.js 中看到的安全和依赖管理问题（The New Stack）。八年后，他在 Hacker News 上坦言，开发者希望 Deno 能兼容 Node.js，这让 Deno 不得不不断补上大家熟悉的功能，结果也越来越像 Node.js。他用一句话概括这种处境：“既然 Node.js 已经能用，为什么还要再造一个？”（Simon Willison 转引）换句话说，Deno 原本想走一条不同的路，却被用户对 Node.js 兼容性的需求拉回了老路。读到这里，我心里有点不是滋味。很多人当年是真心相信 Deno 能为 JavaScript 服务端开辟一条不同的路，我也算其中半个。

单看这件事，可以理解成一位顶级工程师的体面转身。但把日历往前翻，就会看到另一幅图景。1 月，Astro 团队加入 Cloudflare；6 月，Cloudflare 完成对 Vite、Vitest、Rolldown、Oxc 背后 VoidZero 的收购；10 月，Deno 团队宣布加入。九个月内，Cloudflare 的布局已经覆盖构建工具、框架和运行时三个层面。

我做了几年前端，以前从没认真想过 node_modules 里那些包“归谁”。现在却不能不想。这篇文章想聊聊这件事意味着什么，以及每天和这些工具打交道的人可以怎么应对。

一、三次整合，三个人，三种命运

先把人和事讲清楚，再谈战略。团队加入、公司收购等事件最后往往只剩一行字，但开源项目后来会怎么走，很大程度上取决于创始人当初为什么选择与平台公司结合。

Astro：一个只想把网站做好的框架

Astro 是 2021 年出来的。Fred K. Schott 在宣布加入 Cloudflare 的博客里回忆，那几年的风气，是把所有网站都当应用来写：整包交给浏览器渲染，再为了性能一层层堆上更复杂的方案（Astro 博客）。经历过那个年代的人应该都有体会：公司官网的首屏要等几秒钟，浏览器才能完成页面交互功能的初始化。

Astro 的设计目标很明确：内容型网站的大部分页面可以先在服务器端生成，只有需要交互的部分才交给浏览器处理。这样就不用让整页都变成复杂的前端应用，页面通常也会更轻、更快。同一页面还可以混用 React、Vue、Svelte 等框架（Cloudflare Blog）。我第一次用它重写文档站时，构建出来的 JS 体积小得让我怀疑自己是不是把配置写错了。

后来它越做越大。Cloudflare 公告里列的用户有 Porsche、IKEA、OpenAI，Webflow Cloud、Wix Vibe、Stainless 都拿 Astro 当给客户生成网站的底层框架（Cloudflare Blog）。Schott 说采用量“每年都在翻倍”（Astro 博客）。

但商业模式的问题始终没有解决。Schott 写得挺坦诚，他们尝试过付费托管产品，也探索过电商方向；这些尝试没有像 Astro 框架那样获得用户认同，也曾分散团队精力。官方补充说，Astro DB 后来演化为仍留在核心中的开源、内置数据库客户端；电商探索则被开源，不能简单概括为“产品失败”（Astro 博客）。赞助方面，Netlify 在 2024 年 7 月成为 Astro 的“官方部署合作伙伴”，当时承诺每月赞助 12,500 美元（Astro 博客）。2025 年 9 月的分工是 Cloudflare 与 Webflow 赞助 Astro，Cloudflare 与 Netlify 赞助 TanStack（Cloudflare Blog）。最终，Astro 团队选择加入 Cloudflare。

金额没公开。Astro 公司全部全职员工成了 Cloudflare 员工，项目继续 MIT 开源、保留开放治理，也继续支持 Cloudflare 以外的部署平台（Astro 博客）。

VoidZero：尤雨溪的第三次出发

尤雨溪的故事，国内前端开发者都很熟悉。按他自己的说法，2016 到 2023 年他以独立开发者身份维护 Vue 和 Vite，靠赞助维持 Vue 和 Vite 的维护；到 2023 年，这两个项目每周已有数百万次下载。2023 年他创办 VoidZero，想给整个 JavaScript 生态做一套又快又统一的工具链。要做成这件事，需要一支全职团队；仅靠赞助养不起，只好去融风险投资（VoidZero 博客）。2024 年 10 月拿了 Accel 领投的 460 万美元种子轮（VoidZero），2025 年 10 月又融了 1,250 万美元 A 轮，那时已经宣布 Vite 的周下载量超过了 Webpack（VoidZero）。

我还记得前几年在公司里推 Vite 替换 Webpack，要写文档、开会、说服同事。现在回头看，那点阻力早已小了很多。到 2026 年，据 VoidZero 自己的说法，Vite 每周下载超过 1 亿次，Rust 写的 Rolldown 成了 Vite 8 的默认打包器；项目报告称，Oxlint 在大型项目的 lint 速度快 50 到 100 倍，Oxfmt 比 Prettier 快 30 倍，Vite+ 也已改为 MIT 开源。这些性能数字都是项目方自己的基准测试（VoidZero 博客）。npm API 记录显示，2026 年 10 月 3 日至 9 日，vite 包发生约 1.956 亿次下载事件（npm API）。这个数字包含 CI 和机器人安装，不等于真实用户数，但足以说明 Vite 的普及程度。

问题还是那个老问题。尤雨溪原话是：“尽管工具的采用快速增长，我们还没有解决变现问题。”他们试过给 Vite+ 用混合许可，“感觉不对”；又去做跑在 Cloudflare 上的部署平台 Void，结果本来就紧张的人手被拆成两半（VoidZero 博客）。另外，两家在谈收购之前就已经在 Vite Environment API 和 Cloudflare 的 Vite 插件上合作很深了，所以这笔交易其实不算突然。

这笔交易有公开的财务记录：收购于 2026 年 6 月 1 日完成，6 月 4 日对外宣布。根据 Cloudflare 季报，购买对价为 1.642 亿美元（9,870 万美元股票加 6,550 万美元现金）；另有 1.064 亿美元的股票薪酬奖励，单独核算，不属于购买对价。其中剩余的 9,880 万美元薪酬费用将在加权平均 3.9 年内确认，前提是领取者继续在职。注意这是会计上的费用确认，不等同于法律意义上的股票归属（vesting）条款（Cloudflare 10-Q、VoidZero 公告）。

这里插一个小插曲。有媒体标题写“Cloudflare 以 100 万美元收购 VoidZero”（ChannelLife），其实是把 100 万美元的 Vite 生态基金当成了收购价，两者差了两个数量级。我看到时笑了一下，但也有些无奈：连交易规模都能传错，社区对这类交易的认知有多混乱，也就可想而知了。

Deno：Node 之父的第二次尝试

Deno 由 Ryan Dahl 和 Bert Belder 联合创立，前后融了大约 2,600 万美元，包括红杉领投的 A 轮（TechCrunch）。后来他们做了 Deno Deploy，正面跟 Cloudflare Workers 打。

转折出现在 2026 年 8 月的 celld。celld 是一个用 Rust 编写的单文件程序，以对象存储为基础，目标是支持与 Cloudflare Workers 和 Durable Objects 相同的编程模型（Cloudflare Blog）。The New Stack 的标题一点不客气：Cloudflare 收购了那家“照搬其无服务器打法”的创业公司（The New Stack）。Cloudflare 的 Kenton Varda 在联合博文里说，看到 celld 时他们挺高兴，因为这正是他们自己想做却一直没做的东西。他还顺手反驳了一个流传很广的说法，即 Cloudflare 故意把 Workers 做得跟别人不一样来锁定用户。他的意思是，开源、给人留逃生通道，本身就是好生意（TechCrunch）。

这话我愿意信一半，另一半要看后续怎么做。

结局就是开头说的那样。Ryan Dahl 和 Bert Belder 去带一个项目，让 workerd 的自托管成为一等公民，把 celld 的代码和思路合进 Cloudflare 的开源运行时 workerd；JSR 包注册表继续运营，迁到 Cloudflare；Deno 运行时和 Deno Deploy 进入倒计时（Deno 官方博客）。

把三个故事放在一起，能看到一个共同点：这些项目在技术上都已经很有影响力，团队也都公开承认变现问题没解决，最后选择与能提供资源的平台结合。不过三者的交易形式、产品处置和后续走向各不相同，不能一概称为“商业失败”。

二、收编潮：一张表看清谁在整合、涉及什么、后来怎样

Cloudflare 不是唯一一家进行收购或团队整合的平台。视野放宽一点，过去几年 JavaScript 基础设施一直在被大公司一块块整合：

公司/平台	项目或团队	时间	所在层级	之后发生了什么
Shopify	Remix 团队加入	2022 年 10 月	框架	Shopify 的公告称 Remix 团队加入并合作，并未据此确立法律上的收购；Remix v3 改为 React Router v7 是 2024 年 5 月宣布的后续决定，v7 于 2024 年 12 月发布（Shopify Engineering、Remix Blog）
Cloudflare	PartyKit	2024 年 4 月	实时协作框架	融入 Durable Objects 生态（Cloudflare Blog）
Cloudflare	Outerbase	2025 年 4 月	数据库开发体验	公告称计划把 Outerbase 技术整合进 Durable Objects、D1 与 Agents SDK；公告本身不能证明整合已经全部完成（Cloudflare 新闻稿）
Vercel	NuxtLabs	2025 年 7 月	框架与服务器运行时	Nuxt 是框架，Nitro 是服务器运行时；Vercel 承诺两者保持独立、MIT 许可、公开路线图和开放治理（Vercel Blog）
Anthropic	Bun	2025 年 12 月	运行时与全套工具	承诺继续 MIT 开源和开发，服务 Claude Code（Reuters、Anthropic）
Cloudflare	Astro 团队	2026 年 1 月	框架	Astro 承诺保持 MIT、多平台部署、开放治理与公开路线图；Astro 6 本地开发可直接跑在 workerd 中（Astro 博客、Cloudflare Blog）
Cloudflare	VoidZero	2026 年 6 月	构建工具链	6 月 1 日完成收购、6 月 4 日宣布；项目承诺 MIT、不绑定供应商；Void 平台未来将开源（官方计划）（VoidZero、Cloudflare Blog）
Cloudflare	Deno 团队加入	2026 年 10 月	运行时与自托管	官方宣布团队加入；Deno 运行时维护一年后停止开发，Deno Deploy 六个月后关停，celld 的代码与思路将并入 workerd（Deno 官方博客）

注：更早还有 GitHub 收购 npm、Netlify 收购 Gatsby、Vercel 收购 Turborepo，The New Stack 的文章里提到过（The New Stack），具体日期我没有逐一核实。

看着这张表，我有几点感受。

出手的公司大致分三类：Cloudflare、Vercel 这样的云和部署平台，Anthropic 这样的 AI 公司，以及 Shopify 这种有自己主营业务的平台。各自想要什么也不难猜：云平台想承接更多应用部署，AI 公司想让智能体跑得更快、更稳，电商平台需要一个好用的店面框架。

大多数此类安排都许诺“一切照旧”，Deno 是少见的明确叫停核心产品的例子。The New Stack 专门把它和 Bun 放一起对比：Anthropic 承诺继续开发 Bun，而 Deno 运行时的开发会随着并入 Cloudflare 结束（The New Stack）。

还有一条，多少有点扎心。The New Stack 引过 Hacker News 上一条评论：“任何达到临界规模的 JavaScript 工具，都不再能免于被收购。”（The New Stack）我很想反驳，却想了半天也没找到合适的反例。

三、全栈“四层棋”：Cloudflare 和 Vercel 下的是两盘不同的棋

很多人把这一串收购与团队加入理解为 Cloudflare 在和 Vercel 抢开发者。这当然没错，但更值得看的，是两家对“怎么赢下前端”的理解并不一样。

把前端交付链简单拆成四层：构建工具、框架、运行时、部署平台。构建工具这层，Cloudflare 现在手里有 Vite、Rolldown、Oxc、Vitest，Vercel 有 Turbopack 和 Turborepo。框架层，Cloudflare 有 Astro，同时让 Workers 正式支持 React Router v7、Nuxt、SvelteKit 这些主流框架（Cloudflare Blog）；Vercel 的招牌是 Next.js，又迎来 NuxtLabs。运行时，Cloudflare 有开源的 workerd，另有 celld 项目及加入的 Deno 团队；Vercel 的 Functions 运行时也不止 Node.js 和 Edge，还官方支持 Bun、Python、Rust、Go、Ruby、Wasm 和容器（Vercel 文档）。部署层是 Workers、Workers Builds 加上新的统一命令行 cf，对面是 Vercel 平台本身。

Vercel 的路子是把一个招牌框架做到极致，再让它和平台严丝合缝。Next.js 加 Turbopack 加 Vercel，体验确实好，用过的人都知道。但这套优势的前提，是“Next.js 在 Vercel 上最好用”。当然，Next.js 也不是离开 Vercel 就跑不了：官方说许多应用用单个 Node.js 服务器就能部署到任意平台，真正的复杂度集中在多实例缓存同步、按需重新验证、流式响应以及 Edge/Serverless 架构选择上。Next.js 16.2 还推出了稳定的 Adapter API 和共享测试套件，专门改善跨平台适配（Next.js 官方博客）。所以迁移成本主要取决于应用本身和部署架构，并非所有 Next.js 项目都难以跨平台迁移（Cloudflare Blog）。

Cloudflare 走的是另一条路：先占住大家共用的地基，再让默认路径自然地通向自己家。Cloudflare 的博客称，Next.js 以外的许多前端框架都用 Vite 构建，并列举 Astro、SvelteKit、Nuxt、Remix 等项目（Cloudflare Blog）。可以说，Vite 已经是 Next.js 之外多数主流框架共享的底座。

当然它不能把 Vite 私有化，一旦那么干，这块地基就不值钱了。所以，Cloudflare 表示，不会把 Vite 变成自家专用工具；相反，会让自己的应用开发工具建立在 Vite 之上。cf 命令行以 Vite 为基础，Vite 会加上面向全栈应用和智能体的、不绑定平台的新能力（Cloudflare Blog）。

真正的胜负手，我觉得在本地开发。Astro 6 的新开发服务器基于 Vite Environments API，配上 Cloudflare 的 Vite 插件，astro dev 直接在 workerd 里跑你的代码，本地就能调 Durable Objects、D1、KV 和 Agents。官方还特意强调，任何运行时只要给这个 API 写插件，都能获得同样的能力（Cloudflare Blog）。这招很聪明：接口对所有运行时开放，但谁的插件最成熟，谁的开发体验就最顺。而大多数开发者在意的是工具好不好用，不是项目背后的治理结构。

然后是 Vinext，这一步就更直接了。2026 年 2 月，Cloudflare 说一名工程师借助 AI 模型，一周之内基于 Vite 重写了 Next.js 的 API 层。早期基准使用一款 33 路由应用，测的是构建、编译和打包表现，不是生产服务性能；项目报告称构建最多快约 4.4 倍、客户端包最多小 57%，token 花费约 1,100 美元（Cloudflare Blog）。9 月的 1.0 可部署到 Workers、Netlify、AWS Lambda 等平台。它并非“每天与 Next.js 同步”：Cloudflare 说智能体每天审阅 Next.js canary 的新提交、抓取差异并建立跟踪问题，兼容性测试则每晚自动运行（Cloudflare Blog）。换句话说：Next.js 的 API 你可以接着用，构建和部署不一定非得在 Vercel。

Vercel 那边据二手报道反应很大：Vercel CEO Guillermo Rauch 在 X 上称 Vinext 有 7 个安全漏洞，并称其为“vibe-coded”框架（Awesome Agents）。我没能独立核实原帖和漏洞细节，这里只当二手报道看。但就算只当行业八卦，也能看出平台之间争论的焦点已经从价格、性能挪到了框架层。

在我看来，AI 让重写一个框架的成本越来越低，这种情况下 Cloudflare 的底座打法更有延展性，但也更吃信任。Vercel 靠的是体验，体验别人可以追；Cloudflare 靠的是大家相信它中立，这种信任一旦失去，就很难恢复。

四、“供应商中立”到底是什么，以及怎样让它可被检验

几乎每份收购公告都在重复一套说法：MIT 许可，不绑定供应商，社区驱动。我相信写这些话的人多半是真心的。但“中立”这两个字下面其实有好几层含义，分量差别很大。

最表层的是许可。MIT 许可保障了任何人都可以复制和分叉代码，但这并不意味着社区就有能力接手并持续维护项目。fork 的权利在纸面上始终存在，可真要 fork 一个 Vite 这种量级的项目，需要的人手、信誉和协调成本，大概没几个组织扛得住。

再往下是钱。Cloudflare 在 VoidZero 公告中另设了 100 万美元的 Vite 生态基金，由 Vite 核心团队管理，支持 VoidZero 和 Cloudflare 之外的维护者（Cloudflare Blog）。2026 年 8 月，Cloudflare 又宣布了另一笔 100 万美元的开源资助，用于 Community Engineers 计划及多个项目，与 Vite 生态基金是两回事（Cloudflare Blog）。这是好事。不过钱解决的是有没有人干活，解决不了谁说了算。

更要紧的是治理：路线图谁拍板，核心维护者都在哪家公司上班，出了利益冲突谁来裁。Astro 已承诺保留开放治理和公开路线图；VoidZero 也称路线图由更广泛的团队与社区推动、并在公开环境中开发。但就公开资料看，这些项目都没有宣布成立独立基金会或独立法人，治理承诺目前主要靠公司自律。

社区的担心并非空穴来风。VoidZero 那条 Hacker News 主帖有三百来条评论，不少人担心路线图和治理会变（Hacker News）。有人说自己会尽量躲开有风投背景的工具，因为它们最后不是变烂、变贵，就是消失；还有人拿 Cloudflare 当年收购 BastionZero 后产品被关的事来比（The New Stack，这是个人说法，我没法核实）。当然也有乐观的，觉得这就是买人加买产品，Cloudflare 的工程投入是看得见的。

所有官方表态里，我最认同的是 Cloudflare 工程总监 Steve Faulkner 对 The New Stack 说的那句：“我也见过开源项目被收购后承诺被打破……人们应该让我们为此负责。”（The New Stack）

那怎么让他们负责？我的办法很朴素：别看新闻稿，看行为。核心维护者里不在 Cloudflare 上班的人，比例是在涨还是在跌。重要新功能是不是总是 Cloudflare 的适配先发，别的平台等社区慢慢补。Netlify、Vercel、纯 Node 部署这些适配器，跟 Cloudflare 的适配器是不是一样有人管、一样靠谱。说好要开源的 Void 平台，还有 celld 合并之后 workerd 的自托管能力，有没有按时、完整地放出来。项目的治理文档和贡献指南有没有悄悄改过。

这些都不需要内部消息，GitHub 上翻翻就能看到。我们多看几眼，本身就是一种约束。

五、Deno 的结局：温和，但必须当真的警告

公平地说，Deno 这次的处理算体面。有明确时间表，付费客户迁到 Workers 有迁移支持，JSR 继续运营，代码继续开源，也欢迎社区接手（Deno 官方博客）。Ryan Dahl 自己也说这是共同决定，他认同，因为他不再觉得 Deno 运行时是自己能做最重要工作的地方（Simon Willison 转引）。

但我仍然认为，这是整轮收编潮里最值得记住的一课。平台需要的是战略上用得着的那部分，剩下的部分是死是活，要看战略还需不需要。Cloudflare 要的是 Deno 团队的能力和 celld 的自托管模型，它不缺一个 Node 兼容运行时。Deno Deploy 又是 Workers 的直接对手，关掉几乎是必然的。

Hacker News 上有人说得更难听，说标题应该改成“Deno 开发经由 Cloudflare 的 acqui-hire 实质性终止”（HN 讨论镜像，只当情绪参考）。我不完全同意，celld 的思路确实会在 workerd 里活下去。可对那些把生产系统放在 Deno Deploy 上的团队来说，这个区别没什么意义，他们得在半年内搬家。

现在 Vite 和 Astro 正处在 Cloudflare 战略的正中间，我相信它们会被好好对待。只是战略会变，人也会走。前面提到，VoidZero 交易中的股票薪酬费用按加权平均 3.9 年确认，并以领取者继续在职为条件。这个期限不预示任何事一定会发生，但我已经在日历上记了一笔：到时候回来看看，核心那几个人还在不在（Cloudflare 10-Q）。

六、AI 智能体：为什么构建与部署突然变成战略要地

如果只用“抢开发者”来解释这些收购，就会漏掉最大的一块。工具链的头号用户，正在从人变成 AI 智能体。

尤雨溪在公告里说得很直接：“随着 AI 改变格局，我们看到越来越多的工具使用来自 AI 智能体。我们的使命现在包括为智能体打造更好的工具，正如 Cloudflare 正在把自己定位为智能体的云。”（VoidZero 博客）Cloudflare 的收购新闻稿画的图景是：开发者和自主 AI 智能体都可以通过 vite deploy，从一个想法直接走到全球生产环境（Cloudflare 新闻稿）。

可以想象一个现在已经很常见的场景。有人对一个 AI 建站产品说：帮我做个新品发布页，带报名表单。智能体接下来要干的事大概是挑个框架起脚手架，写组件，配构建，跑测试，部署，最后吐出一个能访问的网址。整个过程里它没有品牌偏好，也不会去 Twitter 上看哪个框架最近口碑好。它就挑文档最多、约定最清楚、一条命令能跑通的那条路。

Astro 那篇博客里其实提过这一点：智能体在结构清晰、默认简单的代码库上表现更好，Wix Vibe 这样的 AI 建站产品背后生成的就是跑在 Cloudflare 上的 Astro 站点（Cloudflare Blog）。Ryan Dahl 也说，Durable Objects 那套便宜的无服务器执行、持久状态、WebSocket 加上高层 JavaScript 接口，特别适合拿来做智能体的运行框架（Deno 官方博客）。

把这些线索串起来，链条就清楚了：智能体写代码，需要标准化的脚手架和构建，这是 Vite 和 Astro；代码要跑，需要又快又便宜、彼此隔离的执行环境，这是 Workers 和 Durable Objects；最后要一键部署、能看日志，这是 cf 命令行和 Workers Builds。谁能把每一环都做成默认选项，谁就更有机会承接 AI 生成应用带来的部署需求。不必锁定谁，只要足够顺就行。

Vinext 是这个逻辑最极端的例子。一周时间、一千出头美元的 token 就能重写一个主流框架的 API 层（Cloudflare Blog），说明框架的实现本身在变便宜。我的判断是，真正值钱的不再是代码，而是项目已经形成的标准、社区和开发者习惯。这也解释了为什么一家自称尚未解决变现问题的公司，购买对价仍高达 1.642 亿美元，还不算另外 1.064 亿美元的股票薪酬奖励（Cloudflare 10-Q、VoidZero 公告）。

AI 还在改变维护这件事本身。Cloudflare 讲过他们用 AI“软件工厂”把 Astro 的 GitHub issue 积压清到零（Cloudflare Blog），VoidZero 并进来四个月发了 80 多个版本（Cloudflare Blog）。作为用户我当然乐见其成。但也有点担心：有大公司加 AI 撑腰的项目跑得越来越快，那些还靠几个志愿者周末维护的独立项目，差距只会越拉越大。

七、几个具体场景：开发者与公司该怎么应对

道理说多了容易飘，还是落到几个具体场景上。

如果你是独立开发者，博客和作品集用 Astro 放在 Netlify 上，短期什么都不用动。Astro 明确说会继续支持 Cloudflare 以外的部署目标（Astro 博客）。平时留意一下 Netlify 适配器的更新频率就够了。

如果你有生产 API 跑在 Deno Deploy 上，这是唯一需要马上动手的情况。现在就排迁移计划：迁到 Cloudflare Workers（付费客户官方会帮忙迁），迁到 Node 或 Bun 平台，或者自己托管 workerd、celld，几条路都算算成本（Deno 官方博客）。不要拖到第五个月。依赖 Deno 运行时的内部脚本和工具，也得在一年内想好替代方案。

如果你是一家中型 SaaS 公司的技术负责人，主站是 Next.js 放在 Vercel 上，Vinext 值得盯，但别冲动。它眼下最大的价值，是让你跟平台谈价时手里多一张牌，以及多一条退路。可以先拿营销站或内部工具试试，同时关注它的兼容情况和安全状况。漏洞那件事在出现公开、权威的结论之前，既别拿它当迁移依据，也别因此一棍子打死。

如果你在做 AI 生成网站或应用的平台，从目前公开的产品集成情况看，Cloudflare 这套组合相当一体化：Astro 或 Vite 管生成的项目结构，Workers for Platforms 运行多租户应用，Durable Objects 存状态。代价是你对 Cloudflare 运行时 API 的依赖会明显变深。我的建议是可以用，但在架构上把“生成的应用”和“托管平台”之间那层接口抽出来，定期在至少一个备用平台上跑一遍。

如果你在大公司的架构委员会里定前端技术规范，有件小事很值得做：把“框架和构建工具”跟“托管平台”拆成两个独立决策写进规范。再给关键开源依赖建个健康档案，记下维护者都在哪上班、治理文件是哪个版本、钱从哪来。被收购的这几个项目，每半年拿出来复查一次。

八、对未来两三年的五个预测

先说明一下，下面这些是我的判断，不是内幕；猜错了，欢迎来打脸。

独立的 JS 工具公司会越来越少，要么被收编，要么进基金会。开源工具单独赚钱这道题短期没人解出来，而智能体又让工具链越来越值钱，买家只会变多。
“移交基金会”会变成社区手里的筹码。只要哪天出现一次明显偏向某个平台的路线图争议，要求 Vite 或 Astro 交给中立基金会的声音马上就会冒出来。我猜 Cloudflare 会尽量避免走到那一步，甚至可能主动搞点独立治理的安排。纯属推测。
框架的 API 和构建实现会慢慢分家。Vinext、OpenNext 这种兼容层，会让大家保留熟悉的写法，同时自由挑底下的构建和部署平台。平台之间拼的就是谁的默认路径更顺，谁的本地和线上更一致。
如果 celld 并入 workerd 后让自托管更容易，就能缓解用户对平台绑定的担忧，也可能促使其他平台提供类似方案。
工具链会先为智能体设计，再为人设计。文档、报错信息、命令行输出、配置约定，都会先往机器好读的方向改。前端工程师的一部分价值，会从自己写代码，挪到给智能体定规矩、搭护栏上。

预测是否说中，其实没那么重要。重要的是真发生的时候，你手里有没有牌。

九、给前端开发者与技术负责人的实操清单

个人技能

吃透至少一种“本地即生产”的开发方式，比如 Vite Environment API 配某个运行时插件；
搞懂 isolate 和 Durable Objects 这类有状态无服务器模型大概是怎么回事；
亲手把同一个应用部署到两个不同平台，摸清框架和平台的边界在哪；
学着给 AI 智能体写清楚的项目约定和部署脚本。

团队选型

框架、构建工具、托管平台分开选，理由写下来；
优先选建立在开放标准上、能跨平台部署的组合；
CI 中增加一个备用部署目标的基础测试，例如验证应用能否部署到纯 Node 环境；
业务代码里别深度绑死某个平台的专有 API，必要时包一层薄的。

依赖治理

给关键开源依赖建健康档案：维护者雇主、治理文档、资金来源、发布节奏；
每半年翻一次被收购项目的近况，重点看承诺兑现没有；
订阅项目官方博客和发布说明，少看二手新闻；
社区传闻先打个问号，以一手来源为准。

马上要办的

Deno Deploy 用户：现在就排迁移计划；
依赖 Deno 运行时的项目：一年内评估好替代方案。

结语：我们的选择权，就是最好的治理

我不悲观。Astro、Vite 这些项目过去从未拥有过现在这么多全职工程师和这么宽裕的预算。尤雨溪在 VoidZero 加入 Cloudflare 的公告中说，支持所有开源项目并尊重其社区，是 VoidZero 加入任何公司的前提（VoidZero 博客）。Astro 创始人 Fred Schott 则表示，加入 Cloudflare 后团队可以不再分心于商业模式，把精力放回代码（Astro 博客）。这些目前还只是官方承诺，但作为用户，我确实在享受新增资源带来的好处。

只是我越来越觉得，LICENSE 文件里写着 MIT，并不代表自由会自己延续下去。它需要有人盯着，承诺也必须能被检验；用户手里还得一直保留“随时可以走”的能力。

下次你敲 npm create，或者往配置里加一个插件的时候，可以顺手想一下：这行代码后面，可能站着一家市值上千亿美元的公司。这不一定是坏事，很多时候甚至是好事。但它确实意味着，我们用什么、不用什么，比以前更有分量了。

能随时走，才谈得上让人负责。我打算从自己的项目开始，先把那个逃生用的冒烟测试加上。