八月中旬，前端圈冒出一个新名字：Octane。
它给自己打的标签相当有攻击性——“没有虚拟 DOM 的 React”。知乎、头条上很快出现了一批对比文章，标题基本都是同一个句式：“无虚拟 DOM 版 React 发布，对决 Vue Vapor，谁才是未来？”
如果你平时写 Vue，看到这儿大概率会愣一下：Vapor 是 Vue 3.6 里酝酿了两三年的重头戏，怎么突然就被人"对决"了？这个 Octane 什么来头？那些"Vapor 跑输了"的说法到底靠不靠谱？
我把官网、npm 官方发布记录和多平台的讨论都翻了一遍，今天把这事说清楚。
一、先搞清楚：Octane 是谁
Octane 不是某个大厂的作品，而是一个全新的开源框架，官网 octanejs.dev 开门见山写着：“React’s programming model, compiled”——React 的编程模型，编译化执行。它自称是老牌高性能框架 Inferno 的继任者。
它想做的事一句话就能概括：保留 React 的写法，拿掉 React 的运行时负担。
函数组件、Hooks、Context、Suspense、Transition 这些 React 开发者熟悉的东西，Octane 全都保留。但它靠编译器干掉了三样让 React 开发者头疼多年的东西：
第一，Rules of Hooks。React 里 Hook 不能写在条件语句里，因为运行时靠调用顺序来识别每个 Hook 对应哪份状态。Octane 的编译器在编译阶段就能定位每个 Hook 的位置，所以在 if 里面写 useEffect 是合法的。
第二，依赖数组。useEffect 后面那串 [userId, token, config] 不用手写了，编译器会分析 effect 内部读了哪些值，自动建立依赖关系。
第三，虚拟 DOM。状态变化后不再重新执行组件、生成 VNode 树、做 diff，而是直接定位受影响的 DOM 节点，精确更新——也就是 Solid 用户熟悉的细粒度更新。Octane官网
官网还强调了两点：支持从现有 TSX 逐组件迁移（新的 .tsrx 格式可以和 TSX 共存），以及提供了 94 个一方生态绑定，覆盖状态、路由、表单、图表等常见库。Octane官网
二、"对决"的说法从哪来：那张 benchmark 表
让 Octane 和 Vue Vapor 被放在一起比较的，是 8 月中旬社区流传的、Octane 官方公布的 benchmark 几何平均分（数值越低越好）：
Octane TSRX：1.0×
Vue Vapor：1.2×
Solid 2：1.7×
Svelte 5：2.7×
React 19 + Compiler：4.1×
单看这张表，Octane 第一，Vapor 第二，差距不大。于是"对决""谁才是未来"的说法就传开了。今日头条
但这里必须泼一盆冷水：这是 Octane 自己官网放的 benchmark。我还做了一个交叉核对：8 月下旬打开 Octane 官网的跑分页，每个单元格显示的是该框架相对 Octane（1×）的相对倍数，数值和网上流传的 8 月中旬截图已经对不上了。Octane官网
框架官方跑分这件事，行业里见得多了。测试用例怎么选、哪些场景权重高，直接决定排名。列表更新、组件创建、内存占用、SSR、事件处理，各家在不同场景下互有胜负，官方跑分不能直接等同于真实项目表现。知乎
真正有参考价值的，是 Vue 官方的说法：Vapor 在第三方基准测试中已经展现出与 Solid、Svelte 5 同档的性能。注意，是第三方测试，不是自己跑自己。知乎
三、两条路线的本质区别：一个是换挡，一个是换发动机
抛开跑分，Octane 和 Vapor 其实回答的是同一个时代问题：声明式 UI 是不是非得靠虚拟 DOM？但两者的出发点完全不同。
Vue Vapor 走的是"顺水推舟"路线。Vue 本来就是响应式框架，ref、computed、watch 这套依赖追踪已经跑了多年，模板里读一个 ref，框架自然知道状态和视图的对应关系。Vapor 做的事是：在这套现成的响应式系统上，把虚拟 DOM 这一层拆掉。不改编程模型，不换 API，只是让执行更直接。微信公众号
Octane 走的是"编译器换血"路线。React 的 useState 天生不是 signal，组件读取状态时不会形成细粒度依赖，所以 Octane 必须让编译器去推导"哪个状态对应哪个 DOM 节点"。保留 React 风格的源码，编译后换上一套细粒度响应式的执行模型。路线更激进，对编译器能力的依赖也更重。知乎
用一句圈内的话说：Vue Vapor 是成熟框架的底层换挡，Octane 是一场更大胆、也更依赖时间验证的实验。
四、写 Vue 的你，真正该关注的是这个时间线
与其盯着别人家的跑分，不如看看 Vue 自己这几个月的动作。我查了 npm 上 vue 的官方发布记录，3.6 的推进节奏值得注意：
3.6.0-rc.1：2026 年 7 月 18 日
3.6.0-rc.2：7 月 22 日
3.6.0-rc.3：8 月 11 日
3.6.0-rc.4：8 月 14 日
3.6.0-rc.5：8 月 21 日
从 7 月 Vue 大会上尤雨溪官宣 3.6 候选版，到现在一个多月，RC 版本已经迭代到第 5 个，8 月份明显在加速。与此同时，稳定版仍然是 3.5.41——也就是说，官方在密集打磨，但还没到发正式版的时候。npm
另外两个对 Vue 用户很实际的信息：
Vapor 是可选模式，不是强制切换。你可以在单个组件上加 vapor 标记，也可以通过互操作插件让 VDOM 组件和 Vapor 组件互相嵌套，props、事件、slots 都能正常传。今日头条
官方定位说得很明白：这不是"Vue 4.0 预告"，普通项目升级到 3.6 不会被迫切任何东西。知乎
但限制清单也要看清楚：官方披露的当前限制里明确写着，Vapor 目前仅兼容 Composition API，暂不支持 Options API。今日头条此外，app.config.globalProperties 不能用，getCurrentInstance() 在 Vapor 组件里返回 null，v-memo 和部分模板 ref 能力还没接上。重度依赖这些的项目，短期内跟 Vapor 关系不大。
五、结论：不用焦虑，但值得盯住三个信号
先说结论：Octane 的出现，对写 Vue 的你没有任何直接冲击。它瞄准的是 React 开发者的迁移需求，生态成熟度跟 Vue、React 完全不在一个量级——路由、SSR、调试工具、组件库这些真正决定框架能不能进生产的东西，它还差得远。
但它和 Vapor 共同指向的趋势是真实的：前端框架的战场正在从运行时转向编译器。谁的编译器多做一点工作，谁的运行时就能少付一点成本。这个方向上，Vue 没有掉队，反而因为手里有现成的响应式系统，走得比谁都顺。
接下来值得持续观察的三个信号：
3.6 正式版什么时候发。按目前 RC 的迭代速度，如果 9 月前后落地，说明 Vapor 的稳定性已经过了官方这关。
组件库适配。Element Plus、Ant Design Vue 这些主流库什么时候跟进 Vapor，直接决定它能不能进业务项目。
第三方独立评测。等有人把 Octane、Vapor、Solid 2 放在同一套非官方基准下跑完整场景，那张官方跑分表才真正有了参照物。
在那之前，你的 Vue 3.5 项目该怎么写还怎么写。真要尝鲜，等正式版出来后挑一个性能瓶颈明确、依赖简单的页面试试 Vapor，用自己的数据说话——这比任何跑分表都可靠。
