Vite、Turbopack 与开源的饭碗

写这篇文章的时候，终端里开着的是 next dev --turbo——这个博客本身就是 Next.js。但我手上其他几个项目，几乎全是 Vite。六月看到 VoidZero 加入 Cloudflare 的消息，几件攒了很久的事凑到了一起，想聊聊：

Vite 到底好在哪，坑在哪；
为什么 Turbopack 的热更新体感就是差一截；
一个周下载上亿的构建工具，为什么养不活自己的团队。

Vite 好在哪：开发时「不打包」

Vite 最核心的设计只有一个：dev server 不打包。开发时它直接把源码按浏览器原生 ESM 逐个文件下发，浏览器要哪个模块就现场编译哪个，依赖则用 esbuild 预构建成单个文件。

这个设计带来两个直接结果：

# Vite 启动，项目大小无所谓
$ vite
  VITE ready in 320ms

# 改一行代码，HMR 只重新加载这一个模块
# 项目 100 个页面还是 10000 个页面，速度一样

冷启动和热更新都与项目规模解耦了——因为根本不需要在启动时构建完整的依赖图。

「不打包」是架构层面的答案。架构之上还有一层设计原则，决定了 Vite 能长成什么样。官方的 Philosophy 页写得很清楚，我挑三条对自己影响最深的：

精简可扩展的核心（Lean Extendable Core）：核心只做最常见的场景，长尾需求全部交给插件生态去长。所以 Vite 的配置文件才能那么薄——它的立场是「给你强原语，不替你做决定」；
有立场地推进现代 Web（Pushing the Modern Web）：源码只支持 ESM、浏览器里不许用 Node 模块、Worker 鼓励用 new Worker 标准语法。它不追求兼容一切旧写法，而是「赌」现代标准会成为主流——回头看这个赌注全对了；
为框架而生（Building Frameworks on Top of Vite）：核心 framework-agnostic，SSR 这些原语直接内置。官方原话是 Vite "shines as a tool to create frameworks"——它一开始就是奔着「给别人做底座」去的。

第三条解释了后面的事：Nuxt、SvelteKit、Astro、Remix 全都架在 Vite 上，不是巧合，是它的定位本来如此。选 Vite 不是追新，是整个生态帮你选好了。

Vite 的坑：两套引擎（现在已经统一了）

Vite 有个存在了很多年的结构性问题：开发用的是一套引擎，构建用的是另一套。

开发时是「原生 ESM + esbuild 预构建」，生产构建走 Rollup。两套实现在边角行为上不完全一致，于是就有了那个经典场景：开发的时候好好的，一跑 build 就炸。环形依赖、条件引入、CJS/ESM 边界，都是重灾区。

还有个日常小毛刺：改代码触碰到新的依赖，Vite 会突然提示 new dependencies optimized, reloading page，然后整页刷新，你刚刚填了一半的表单没了。这就是预构建缓存在失效重建。

这件事在 2026 年 3 月的 Vite 8.0 里正式翻篇了：Rolldown——VoidZero 用 Rust 写的新打包器——成为 Vite 唯一的底层引擎，esbuild 和 Rollup 都被替换掉，dev 和 build 跑同一套代码。5 月 Rolldown 1.0 稳定，Vite 8.1 也已经跟进。代价不是没有：社区有大仓库反馈过构建产物变大、chunk 数变多的问题，官方还在打磨。但「双引擎」这个最大的结构性缺陷，确实解决了。

顺带记一条线索：这个「用 Rust 重写统一引擎」的工程，正是 VoidZero 这家公司存在的核心理由——后面讲收购的时候会用到。

那 Turbopack 呢？

先说公道话。Turbopack 是 Rust 写的增量打包器，Webpack 作者的作品，冷启动和大仓库场景确实强。Next.js 16 起它已经转正，dev 和 build 默认都是 Turbopack，官方口径构建提速 2-5 倍。

但日常用下来，热更新的体感就是不如 Vite。我的理解是三层原因：

第一层，架构路线不同。 Turbopack 的本质仍然是 bundler——dev 时也在维护模块图做增量打包；Vite 干脆不打包，改一个文件等于浏览器重新 import 一个 ESM 模块，失效边界天然就是最小的。这是「打包」和「不打包」的路线差异。（Vite 8 换了 Rolldown 之后这点也没变——dev 依然是按需下发原生 ESM，不产出整包。）

第二层，框架层太厚。 这可能是更关键的原因。Next 的热更新链路要穿过 React Fast Refresh 和 App Router：你改一个 server component，触发的是服务端重渲染 + RSC payload 刷新，失效范围天然比「换一个组件模块」大得多。而 Vite + React 的 SPA 只换组件本身。拿 Vite 的 dev server 对比 Next 本身就不对等——Vite 公平的对手是 Nuxt 和 SvelteKit。

第三层，工程成熟度。 Turbopack 还年轻，热更新链路上的部件多——持久缓存、懒编译、dev overlay——每一个都可能抖一下。

所以我的结论是：这是取舍，不是菜。Next 用热更新的毛刺，换来的是大规模仓库下的性能和全栈框架的整合度。（以前还能加一条「dev/build 同引擎的一致性」，但 Vite 8 统一 Rolldown 之后，这条优势不存在了。）另外 Turbopack 不兼容 webpack 插件，重配置的老项目迁移有真实成本（Next 16 留了 --webpack 的逃生门）。

Cloudflare 收购 VoidZero：发生了什么

先把事实线捋清楚（都给了原文链接，感兴趣建议读原文，尤其是尤雨溪那篇）：

2024 年，尤雨溪（Vue 和 Vite 的作者）创办 VoidZero，接手 Vite / Rolldown / Oxc 的全职开发，种子轮 460 万美元（Accel 领投）；
2025 年 10 月，A 轮 1250 万美元（Accel、Peak XV 等）；
2026 年 6 月，官宣加入 Cloudflare（VoidZero 侧公告），团队进新兴技术部门，Vite、Vitest、Rolldown、Oxc、Vite+ 全部保持 MIT 开源，Cloudflare 另外投 100 万美元做生态基金。

这条新闻里最值得读的是尤雨溪自己写的那篇公告，坦白得少见。关于「为什么卖」，他几乎没绕弯子：

我们还没有解决变现问题。（Vite+ 的混合授权实验）感觉不对。做自己的部署平台，把本就人手不足的团队劈成了两半。

翻译成事实就是三件事：

变现没跑通。他们试过给 Vite 做商业化增值（Vite+），采用混合授权，但社区观感不佳，收购前先把 Vite+ 改回了纯 MIT——等于亲手承认这条路走不通；
自建平台分散了火力。为了商业化他们做了自己的部署平台 Void，工具团队被分走一半去搞云，而云基础设施并不是他们的强项；
Void 本来就架在 Cloudflare 上，两边早就在 Environment API 和官方 Vite 插件上深度合作过，与其自己硬扛，不如加入。

Cloudflare 那边的官方博客也有两句值得记下来的表态。一句是立场：「让整个 Web 生态都围绕单一厂商构建，是不合理的」（有意思，这话出自一家正在收购基础设施的厂商）；另一句是承诺的方向：「我们不是把 Vite 搬向 Cloudflare，而是反过来——把 Cloudflare 的工具链搬到 Vite 上」。

落到产品上的动作也很具体：基于 Vite 的 Environment API，vite dev 可以直接跑在 workerd（Workers 的开源运行时）里，KV、R2、D1 这些绑定在本地就能用；未来 cf dev 会是 vite dev 的超集。Cloudflare 自己的仪表盘就跑在 Vite 上，插件周下载 1400 万——吃自己的狗粮这件事，至少是认真的。

另一个有意思的动机：AI agent 正在成为工具链的重度用户（Cloudflare 的原话大意：agent 写的应用正在选 Vite，而且越来越多地选跑在 Cloudflare 上的 Vite）。工具链 + 云 + agent 的故事，讲得通也做得到。

为什么这么出名的开源养不活自己

这才是我觉得最有味道的部分。

Vite 周下载量上亿（Cloudflare 收购公告给的口径是约 1.29 亿，Vite 8 发布时是 6500 万——短短三个月翻了倍，agent 时代的需求可见一斑），是这个星球上使用最广的开发工具之一。它背后的全职团队多少人？十来个。

问题出在哪：下载量不等于收入。

构建工具太底层了，它不直接产生业务收入，公司愿意为「用了赚钱的产品」付费，却很难为「每天免费白嫖的基础设施」掏钱；
使用者绝大部分是搭车者。全球几百万个项目、无数商业化产品建立在 Vite 上，但赞助收入覆盖不了一个十人团队的工资；
基金会能给治理，给不了薪水。

Vite 不是孤例。core-js 的作者长期靠募捐，那个项目几乎被每个前端项目传递依赖；Babel 和 webpack 常年资金紧张；left-pad 和 faker.js 则展示了另一条崩溃路径——维护者直接删库跑路。

盘一圈，开源工具的活路其实就那么几条：被收购（最现实的退出）、Open Core / 云服务（Vite+ 试过，放弃了）、双许可（社区反弹激烈）、基金会化（慢，且不解决钱）。VoidZero 走的是第一条。

站在 Cloudflare 的角度这笔账很好算：买下团队和工具链话语权，比自研便宜太多。对标也现成——Vercel 有 Turbopack，Microsoft 收了 npm 和 GitHub。基础设施厂商吞掉开源工具链，已经是大厂的标准动作。

一点个人想法

两个担忧和一个启示。

担忧一：中立的底座落进了单一厂商手里。Vite 是 Nuxt、SvelteKit、Astro、Remix 的公共地基，而 Cloudflare 是其中一家平台的经营者。好在它是平台方不是框架方（比「框架公司收购框架」好得多），好在承诺都白纸黑字——MIT 保留、团队继续主导、那句「我们不是把 Vite 搬向 Cloudflare，而是反过来」，连 100 万美元生态基金的官方说辞都是「Vite 比 VoidZero 和 Cloudflare 都大」。姿态是对的，但未来路线图会不会优先服务 Cloudflare 的场景，值得长期盯着。

担忧二：这是不是在鼓励「先开源圈地，再卖给巨头」。对创作者是好事（终于有钱了），但对整个生态，悬在头上的问题没变：下一个养不活自己的基础设施项目，去哪里找它的 Cloudflare。

启示很朴素：依赖即责任。你的项目每天在跑的工具有多稳定，取决于维护它的人过得好不好。能付费的产品考虑付费，重度依赖的库去 sponsor 一下——这不慈善，这是给自己脚下的地基浇点水。

至于我自己的选型，这次收购没有改变任何事：全栈应用继续 Next（接受 Turbopack 热更新的小毛刺，换全栈整合度），纯前端和工具类项目继续 Vite（Vite 8 + Rolldown 已经稳定，排期升上去）。

总结

工具层面：Vite 赢在「开发不打包」的架构和整个新框架生态，Vite 8 统一引擎后最大的短板也补上了；Turbopack 赢在大仓库性能和全栈整合，热更新的体感差异主要是架构取舍而非能力差距。

行业层面：开源的钱问题没有银弹。一个周下载上亿的工具养不活十个人，靠的不是理想主义续命，就是找到一个 Cloudflare。

写完这篇，看了眼旁边还在跑的 next dev --turbo，还有几年前那篇写 Vite 与 Webpack 选择的旧文。工具换了一茬又一茬，不变的是：总有人在不计回报地替所有人修路。路修好了，别忘了修路的人。