2026 年 Vue 发展现状

约 3230 字大约 11 分钟

VueVue3.6Vapor Mode生态

2026-09-16

时间基准

本文信息截至 2026 年 9 月 16 日。Vue 3.6 当时仍处于 RC 阶段（最新 v3.6.0-rc.8），部分 API 与数据可能在正式版发布后有所调整，请以官方 Release Notes 为准。

概述

2026 年是 Vue 近几年变化最大的一年，但这种"大"不体现在 API 上——几乎没有面向应用开发者的破坏性变更，而是体现在底层：

层级	2026 年的变化
渲染层	Vapor Mode——编译期生成命令式 DOM 操作，可选地完全绕过虚拟 DOM
响应式层	`@vue/reactivity` 基于 alien-signals 重写，全量默认生效
构建层	Vite 8 用 Rust 编写的 Rolldown 统一替换 esbuild + Rollup
元框架层	Nuxt 4.4 / 4.5 迁移到 Vite 8，为 Nuxt 5 铺路
状态层	Pinia 3 稳定，Pinia Colada 发布首个正式版补齐服务端状态

一句话概括 2026 年 Vue 的主线：性能优先，API 稳定。Vue 团队选择了一条"不折腾用户"的路径——把所有激进改动放在编译器、运行时和工具链内部，让存量项目升级几乎零成本。

版本时间线

Vue Core

时间	版本	说明
2026-07-18	`v3.6.0-rc.1`	进入 RC 阶段，Vapor Mode 特性完备
2026-07-22	`v3.6.0-rc.2`	事件委托改为 opt-in（RC 阶段主要破坏性变更）
2026-08-05	`v3.5.41`	稳定线维护版本
2026-08-27	`v3.5.42`	当前稳定线最新版
2026-09-11	`v3.6.0-rc.8`	当前 RC 线最新版
2026 秋季（预计）	`v3.6.0`	正式版

当前生产环境的默认选择仍是 3.5.x；3.6 需等待正式版落地。

生态

时间	事件
2026-03-12	Vite 8.0 正式发布，Rolldown 成为唯一打包器
2026-05-07	Rolldown 1.0 稳定发布，API 锁定并提供向后兼容保证
2026 年初	Pinia Colada 首个稳定版
2026 年内	Nuxt 4.4 / 4.5 发布，构建层迁移至 Vite 8，Nitro v3 进入 beta

Vue 3.6：本年度的核心版本

alien-signals 响应式重构

这是 3.6 里影响面最广的改动——它不需要 opt-in，升级到 3.6 后所有项目自动生效。

Vue 的响应式系统被重写在 alien-signals 之上，这是一个专为最小化依赖追踪开销而设计的信号库。

核心机制：push-pull 两阶段算法

push 阶段：signal 变更时，向所有依赖它的 computed 传播 "dirty" 标记
          ——只翻转 boolean flag，不执行任何计算，成本极低
          
pull 阶段：computed 被读取时，检查 dirty 标记
          ——脏则重新计算，干净则直接返回缓存值

关键实现变化

维度	Vue 3.5	Vue 3.6（alien-signals）
依赖存储结构	`Set`	双向链表
依赖清理	遍历 Set 重建	链表节点直接摘除，分配更少
通知机制	逐个触发	更激进的批处理（batching）
内存占用	基准	约 -14%

双向链表替代 Set 是这次重构的关键：每个响应式依赖的内存占用更小，清理陈旧依赖时的遍历速度也更快。

升级注意

虽然是内部重构，但依赖时序的复杂 watch / effect 链路建议做一轮回归测试。官方建议：先单独验证响应式升级，再考虑迁移 Vapor，不要两件事一起做。

Vapor Mode

是什么

Vapor Mode 是一种新的 SFC 编译模式，它把单文件组件直接编译成命令式的 DOM 操作代码，完全跳过虚拟 DOM 的 diff 层——而 vDOM 从 Vue 2.0 起就是渲染模型的核心。

本质上，diff 从运行时挪到了构建时。这条路线和 Solid.js、Svelte 5 采用的编译时优化思路一致。

传统 vDOM 模式：
  模板 → render 函数 → VNode 树 → diff → patch → 真实 DOM

Vapor 模式：
  模板 → 编译期分析 → 直接的 DOM 操作指令 → 真实 DOM

启用方式

1. 单组件启用

在 <script setup> 上加 vapor 属性即可，模板和 setup 逻辑完全不变：

<script setup vapor lang="ts">
import { ref } from 'vue'

const count = ref(0)
</script>

<template>
  <button @click="count++">{{ count }}</button>
</template>

<script vapor> 是它的简写形式。

2. 全 Vapor 应用

新项目或独立子应用可以用 createVaporApp 彻底跳过 vDOM runtime，基础包体积可降到 10KB 以下：

import { createVaporApp } from 'vue'
import App from './App.vue'

createVaporApp(App).mount('#app')

3. 混合模式（存量项目的主要路径）

在传统 vDOM 应用中使用 Vapor 组件，需要注册互操作插件：

import { createApp, vaporInteropPlugin } from 'vue'
import App from './App.vue'

createApp(App)
  .use(vaporInteropPlugin)
  .mount('#app')

反过来，全 Vapor 应用要引入传统 vDOM 组件（比如尚未适配的第三方 UI 库），同样注册这个插件：

import { createVaporApp, vaporInteropPlugin } from 'vue'
import App from './App.vue'

createVaporApp(App)
  .use(vaporInteropPlugin)
  .mount('#app')

标准的 props、events、slots 都能跨越 Vapor / vDOM 边界正常工作；但部分 prop 响应式模式和 slot 边界情况在跨边界时行为有差异，混合使用时需要重点测试。

不支持的特性

Vapor Mode 不支持任何依赖 VNode 或组件公开实例代理的能力。官方明确列出的清单：

不支持项	说明
Options API	只支持 Composition API + `<script setup>`
`app.config.globalProperties`	全局属性注入不可用
`getCurrentInstance()`	返回 `null`
`@vue:xxx` 生命周期事件	元素级生命周期钩子不可用
`v-memo`	依赖 vDOM 的缓存指令
`$el` / `$props` 等实例代理属性	组件模板 ref 上取不到
自定义指令	需迁移到 Vapor 专用的函数式接口

另外一个容易踩的坑：在 Vapor 中把 slots.default?.() 当"探针"来判断插槽是否存在可能触发副作用，应该交给模板去渲染，而不是在 script 里主动调用。

性能表现

官方定位是"性能与 Solid 和 Svelte 5 持平"。第三方基准测试报告的数据：

指标	数据	来源性质
渲染速度	极端场景下最快提升 97%	第三方基准
挂载吞吐	10 万组件约 100ms	第三方基准
包体积	Vapor-only 组件小 20%–50%	第三方基准
首屏 JS	报告降低约 2/3	第三方基准
运行时内存	报告接近减半	第三方基准

关于这些数字

除"与 Solid/Svelte 5 持平"这一条来自官方描述外，上表数据均来自第三方评测博客，且多为极端合成场景（大列表、高频更新）。真实业务应用的提升幅度通常远小于此，务必在自己的性能敏感页面上实测，不要直接套用。

除了去掉 vDOM 本身，3.6 还对 Vapor runtime 做了针对性瘦身：slots、Teleport、Transition、KeepAlive、Suspense 这些特性的未使用路径会被更激进地 tree-shaking 掉。

SSR 与 Hydration 改进

静态模板 hydration 快速路径：以静态内容为主的页面，首次渲染速度显著提升
Vapor 组件 hydration 更可靠：配合 Nuxt 等 SSR 框架使用时 mismatch 更少
互操作性改进：Vapor 与传统 vDOM 组件混用的摩擦降低，尤其是需要暴露灵活 slot API 的可复用 Vapor 组件

从 3.5 升级到 3.6 的注意事项

升级 3.6 不会自动启用 Vapor——Vapor 是 100% opt-in 的，不加 vapor 属性就还是原来的行为
响应式重构是全量生效的——复杂 watcher/effect 需要回归测试
RC.2 的破坏性变更：事件委托改为 opt-in
RC.1 中 Vapor 默认使用 document 级事件委托，RC.2 改为默认直接绑定到元素。确实需要委托时显式声明：
```
<button @click.delegate="onClick">Save</button>
```
同时需要移除项目中已有的 compilerOptions.eventDelegation 配置。
自定义指令需要单独迁移到 Vapor 的函数式接口

官方推荐的采用策略

Vue 团队的建议非常克制，明确不推荐全量迁移：

✅ 存量应用中性能敏感的局部页面启用 Vapor
✅ 全新的小型应用整体使用 Vapor
❌ 大型存量应用一次性全量迁移

构建工具链：Vite 8 + Rolldown

Vite 8（2026-03-12 发布）

Vite 8 是架构层面的重大转折：用统一的 Rust 方案替换了原先的双打包器策略。此前 Vite 开发环境用 esbuild、生产环境用 Rollup，两套语义难免有差异；Vite 8 让 Rolldown 成为所有环境的唯一打包器。

真实项目的构建时间数据（官方公布的 preview/beta 阶段用户反馈）：

项目	效果
Linear	46 秒 → 6 秒
Beehiiv	构建时间减少 64%
Mercedes-Benz.io	构建快 38%

官方口径是大型代码库上"最高 10–30 倍构建提速，同时保持完整的插件兼容性"。

Vite 8 的其他新增能力

Vite Devtools 集成，内置调试能力
resolve.tsconfigPaths——原生支持 TypeScript 路径别名
WebAssembly SSR 支持
浏览器 console 转发到 dev server 终端
内置 emitDecoratorMetadata 支持

代价：安装体积比 Vite 7 大约 +15MB（lightningcss 转为标准依赖约 10MB，Rolldown 二进制约 5MB）。

Environment API 仍在推进稳定化中，Vite 团队与生态维护者保持定期协作会议。

Rolldown 1.0（2026-05-07）

Rolldown 早于 Vite 8 稳定版之前就发布了 1.0，API 已锁定并提供向后兼容保证，同时也可以脱离 Vite 独立使用。

这套工具链（Rolldown / Oxc / Vite）由 Evan You 创立的 VoidZero 主导推进，目标是用 Rust 重写整条 JS 工具链。

Nuxt：4.x 与通往 Nuxt 5 的路

Nuxt 4.4 / 4.5 是 2026 年的主力版本，仍是需要 SSR、SSG、API routes 场景的推荐元框架
构建层已迁移到 Vite 8，带来更快的冷启动和 Rolldown 驱动的内部优化
Nuxt 4.5 的相当一部分内容是为 Nuxt 5 做的铺垫，可以通过配置项 opt-in 到未来的前向兼容行为
Nitro v3（JS server engine）已进入 beta，这是 Nuxt 5 的前置条件之一
Nuxt UI 迭代到 4.8，持续新增组件
Nuxt 团队还把自研 AI agent 直接集成进了 nuxt.com，用于答疑和生成 UI 原型

请求缓存
请求去重（deduplication）
后台重新校验（background revalidation）
乐观更新（optimistic updates）

它现在是 Vue 应用做 API 集成的推荐方案，角色类似 React 生态的 TanStack Query。

Vue Router

Vue Router 在 2026 年补齐了呼声很高的能力：

原生支持 View Transition API——页面切换动画不再需要手动 hack

生态与社区

调研显示 93% 的开发者计划在下一个项目中继续使用 Vue，其中 80% 表示"一定会"（几年前这个数字是 74%）
Vue 2 已于 2023 年底 EOL，社区迁移基本完成
Vue DevTools 与 Pinia 3 的集成更完善；社区还出现了 Colada DevTools 这样支持 Pinia 时间旅行调试的工具

实践建议

如果你在维护存量 Vue 3 项目

短期不要急着上 3.6 RC，等正式版发布并观察 1–2 个 patch 版本
正式版发布后，先升级到 3.6 但不启用 Vapor——白拿 alien-signals 的性能提升，重点回归测试复杂 watcher
构建层可以先行升级 Vite 8，收益最大且风险最低（注意 +15MB 安装体积）
挑 1–2 个性能确实有瓶颈的页面试点 Vapor，实测数据说话

如果你在启动新项目

Vue 3.5 稳定版 + Vite 8 + Pinia 3 + Pinia Colada 是当下最稳的组合
需要 SSR/SSG → Nuxt 4.5
如果是小型应用且性能敏感，可以考虑正式版发布后整体用 createVaporApp，前提是接受"不能用 Options API、部分第三方 UI 库需要 interop 插件"这些约束

关于 Vapor 的心理预期

Vapor 不是"升级就变快"的银弹：

它要求 Composition API + <script setup>，Options API 项目无法直接受益
第三方 UI 库需要时间适配，跨边界的 slot / prop 行为需要实测
官方自己都建议局部采用，不必着急做技术决策

javascript

typescript

Flutter

React Native

Taro

uni-app

webpack

vite

rspack

脚本世界

规范先行

代码风格

ESLint

代码质量

工程设计

效率工具

持续集成与部署

运维与基础设施

Monorepo

核心基础

路由与状态

渲染与框架

实践与优化

2026 年 Vue 发展现状