Vue x Vite Conf 2026 总结
写在前面
作为一名仍在坚持古法编程的开发者，参加这次大会时，我内心有些忐忑。此行也是为了在风云变幻的AI浪潮中，如何重新找回作为小小前端工程师的信心与勇气。2026.7.18，在 Vue Conf 的会场上，我找到了答案。
我开始反思：一个已经停滞的技术人，还能继续向前吗？又该如何面对被 AI 席卷的世界？
尤大带来了 Vue 和 Vite 生态的最新进展；Edison 拆解了 Vapor Mode 从编译器到运行时细粒度更新的心智模型；黄玄把 Lynx 与 Vue 结合，让“Vue Native”从愿景走向现实；雪碧大神更是让 PocketJS 在不到 8MB 的内存里流畅运行。 Vue Vaper——这一切都在告诉我：前端没有死，它只是在以更底层、更高效、更跨界的方式重生。
而那些在谷歌发布 Gemini 时高喊“前端已死”的人，和几年前追捧低代码的大概是同一批吧。他们总在唱衰什么“已死”，其实只是在变革中选择了固守。 真正的开发者，正像 shulaoda 那样钻研 Vite 与 Rolldown 的内存优化，像杨启明那样用 Weapp-vite 重新思考小程序工程化，像洛灵与 Neko 那样把 Vue 塞进没有 DOM 的环境里去跑 Agent —— 他们让我一个每天写业务代码的小小开发眼前一亮。
技术与勇气，从来与完美无关，而在于动荡中持续重构自我。前端如此，人生亦然。
Vue 和 Vite 生态最新进展 by Evan
快速记录
✅ 附演讲地址：【2026】Vue & Vite 生态最新进展 / 尤雨溪
✅ 尤大提到的一些链接：
| Name&Link | Desc |
|---|---|
| js-framework-benchmark | 专门用于比较不同前端框架（如 Vue, React, Svelte 等）性能的基准测试项目 |
| reactive-framework-test-suite | 用于检查响应式系统在各种边界情况下行为是否正确的测试集 |
| Pinia4.0 | Pinia 4.0 正式发布 |
| Vizejs | 基于Rust和Oxc的高性能Vue工具链 |
| Verter | 实验性的Vue工具链+LSP实现 (Language Server Protocol) |
| Golar | 基于tsgo的嵌入语言支持框架，对不同文件的支持的一种探索方向 |
| tsgo Native Bridge | tsc的无感替代，但底层由tsgo执行，兼容现有依赖tsc的工具vue-tsc个人觉得Golar和tsgo Native Bridge是Vue团队解决TypeScript工具链的速度问题,Evan表示tsgo时代Vue语言支持仍在探索阶段 |
| 基于Vue多终端渲染方案 | Vue Native on Lynx、PocketJs、weapp-vite、Vue-Termui、Uni-app蒸汽模式、Vue-tui by Simon-He等。 |
| Vite 8.0 | 完全迁移到Rolldown，用Rust彻底重构底层打包能力，同时顺手把开发中常见的痛点（路径别名、调试）内置化，并主动拥抱AI编程的新工作流。 |
| Vite+ | 基于Nodejs整体增强JS开发体验，用 vp 一个命令搞定运行时、包管理器、以及前端栈。 |
| Void | Vite原生部署平台，一个Vite插件把Vite前端应用变成部署在Cloudflare的全栈应用。 |
关于AI时代Evan的建议
我第一次见到活的尤大，茶歇时间还合影了，很激动！从Vue创始人的角度，尤大说在AI的加成下，使用Vue的用户差不多翻了一倍。尤大的演讲注重在AI时代下框架设计的一些思考，如下图：（虽然我现在是个小开发，也许以后就能提交pr呢，梦想还是要有的🤪～）
尤大说了很多，但我只记住了如果更新Vue4，API的设计基本沿用Vue3不变，用专业的说法就是API的设计应该偏重一致性，因为AI模型训练对框架已经成型了。 终于不用经历刚开始Vue2到Vue3转变的忐忑。我想起了以前加班重构项目吓得半死😱，生怕自己弄错了。
尤大说自从有了AI后，重写这件事变得非常容易。只要你有正确的思路想法，把决定做对就可以了。
用AI开发时，模型需要实现一个功能，生成了一堆代码，重要的是使用者如何决定下一步该做什么？静态纠错linting(首先去检查模型有没有犯错、是否遵循项目规范)、格式formatting、验证build/hmr+testing，这三步做好就不会失控。
如何压缩工具的使用时间？Evan再次安利了Vite+
深入理解 Vapor Mode by Edison
快速记录
✅ 附演讲地址：深入理解 Vapor Mode / Edison
从模板到更新指令：Vapor Mode 的编译策略
Vapor Mode 是 Vue SFC 的一种新编译策略：
VDOM vs vapor 的 核心差异：
那么编译器是如何做的：
在 compiler-vapor中，会将template 编译进 setup body 中：
关于产物分析，图右侧是图左点击按钮后发生的编译变化：
以下是对五个产物阶段的详细说明
产物1️⃣阶段：
产物2️⃣阶段：
产物3️⃣阶段： 在默认情况下，Vapor模式会走事件委托的逻辑，但同时需要满足以下四个条件：
事件委托的好处是同一种事件我们只需要在document上监听一次就可以，每个元素只保存自己的handler，不需要每个事件都调用addEventListener.但事件委托也存在限制：事件委托依赖冒泡，如果任意父节点上的函数调用了stopPropagation(),那就无法到达目的地，委托逻辑就不会执行。
那么如何处理这个限制？可以采用动态绑定；或者在编译过程中禁用eventDelegation:
产物4️⃣阶段：
产物5️⃣阶段：
从编译产物到 DOM 更新：动态 Block 的运行原理
INFO
静态 Block 指的是模板中没有任何动态绑定的纯 HTML 元素,如 <div class="fixed">hello</div>。这类节点在 Vapor 编译时会被静态提升（hoist）或直接生成，它们没有独立的更新逻辑，也无需响应式追踪——创建一次，永久驻留。
坦白说，我曾以为 Vapor Mode 只是换了一种代码生成风格，类似将 Vue 模板编译成 React Hooks 式的写法。但 Edison 用 DynamicFragment、ForFragment、SlotFragment 这些精心设计的抽象，让我意识到：Vapor Mode 并非对虚拟 DOM 的粗暴删减，而是一次从编译到运行时的深思熟虑的重构。
从视频 9'50" 开始，Edison 正式进入 动态 Block 的剖析，涵盖了 v-if、v-for、<slot> 和自定义组件这四大动态场景。其核心是在阐明：Vapor Mode 如何以“动态 Block”为基本单元，将 Vue 模板编译成一棵支持细粒度更新的响应式 DOM 树，从而在舍弃虚拟 DOM 的同时，依然保持声明式的优雅与极致的运行时性能。
1、什么是“动态 Block”？
在 Vapor Mode 下，Vue 编译器会将如下转换：
v-if、v-for、<slot /> 和自定义组件 => createIf / createFor / createSlot / createComponent
这些函数返回的实例（Fragment/Instance）就是动态 Block。它们会被平铺在 setup() 的返回值数组中，Vapor 运行时不再像传统 Vue 那样递归地构建 VNode 树，而是直接拿到这些“动态块”进行操作。
2、v-if → createIf：条件块如何切换？
核心逻辑：_createIf 内部会创建一个 DynamicFragment 实例。它利用一个锚点（Anchor） 作为占位符（始终留在 DOM 中），条件为真时渲染分支内容，为假时移除分支内容。
作用域隔离：分支内的所有响应式 Effect（如文本更新）会被收集到该 Fragment 的 scope 中。当条件切换为假时，Vapor 会调用 scope.stop() 一次性清理所有相关的副作用，避免了内存泄露——这是细粒度更新的基础。
3、v-for → createFor：列表块如何更新？
_createFor 返回的是 ForFragment 实例，它管理着一个 ForBlock 数组（每个列表项对应一个 Block）。
当数据源 list 变化时，Vapor 内部会执行一套高效的 Diff 算法，来决定是挂载（mount）、复用（reuse）、移动（move）还是移除（remove） 现有的 ForBlock，而不是暴力重建整个列表。每个 ForBlock 内部也包含自己独立的 scope，保证每个列表项的响应式状态互不干扰。
4、<slot> → createSlot：插槽的两种模式
① 稳定插槽（Fast Path）
当插槽的 content（传入内容） 和 fallback（默认内容） 之间不存在运行时切换可能时（比如没有 fallback，或 slot 名称静态匹配），就直接走 fast path，createSlot 只返回一个简单的 DynamicFragment，不做任何切换逻辑。
② 不稳定插槽（Unstable Slot）
当插槽内容里有 v-if / v-for 等动态指令，导致 content 可能“有内容”也可能“空”时，就需要在 content 和 fallback 之间动态切换。
此时编译器会把插槽内容中根级的 v-if / v-for 标记为 SLOT_ROOT，并在它们更新时通知外层 SlotFragment 重新检查：
如果 content 中任意一个根节点有效 → 显示 content
如果 content 中所有根节点都无效 → 显示 fallback
核心难点：Vapor 的 setup 只执行一次，插槽内容内部的 v-if 是独立更新的，外层 Slot 必须能“感知”到内部 validity（有效性）的变化。SlotFragment 就是用来解决这个“嵌套动态块通知”问题的。
5、createComponent → 组件的 Block 如何挂载？
组件本身也是一个 Block，但它不会立即执行子组件的逻辑。父组件只传一个 getter（取值函数），子组件需要用 props.count 时才真正读取,即“懒求值”，能有效避免不必要的重复渲染。
Hydration
INFO
由于我之前做的都是CSR项目，非常惭愧🫣对这个概念不熟悉。对此我也恶补了这个知识点，写在这篇博客中。
🤖 Hydration是什么？
这是一个化学词汇的借用（如无水硫酸铜吸水变成蓝色的水合硫酸铜），在这里，把“静态的 HTML 骨架”比作“干燥的粉末”，把“JavaScript 逻辑和状态”比作“水”，两者结合后，页面才真正“活”了过来。
再专业一点，就是服务端渲染（SSR） 和同构应用（Isomorphic/Universal App） 领域的核心术语。
🤖 Hydration为了解决什么？
为了解决 “首屏性能”与“交互体验”之间的矛盾。既让用户极快地看到完整内容（SSR的优势），又能拥有单页应用丝滑的交互（CSR的优势）。
🤖 以点击按钮为例，对比CSR/SSR/SSR + Hydration：
| 阶段 | CSR（裸奔） | SSR（纯静态） | SSR + Hydration（最佳方案） |
|---|---|---|---|
| 用户第一眼看到 | 白屏 / Loading | 完整的按钮和数字 | 完整的按钮和数字 |
| 用户点击按钮时 | 响应极快，Vue 全权掌控 | 无反应 | 响应极快，Vue 接管了 DOM |
| Vue 做了什么 | 创建 DOM + 绑定事件 | 未参与渲染 | 不创建 DOM，只绑定事件 + 接管控制权 |
| 关键成本 | 等待 JS 下载执行 | 服务器压力大 | 比对 DOM 结构（若对不上会报错），事件绑定的开销 |
🤖 为什么 Vapor Mode 要特别关注 Hydration？
因为 Vapor Mode 抛弃了虚拟 DOM。它不像传统 Vue 那样有“内存中的 DOM 副本”可以用来和真实 DOM 做精细比对。
🤖 Vue从哪个版本抛弃了虚拟DOM？对使用者有什么影响？
Vapor Mode 从 Vue 3.6 开始作为可选的编译模式引入，没有强制替换现有模式。
对开发者而言，99% 的日常代码写法无需改变，只需在想要开启的组件或应用上添加特定标识即可：
按组件开启：在
<script setup>标签上添加 vapor 属性：<script setup vapor>。整个应用开启：使用 createVaporApp() 来代替 createApp() 创建应用。
🤖 Hydration 无法单独运行吗？
是的，Hydration 必须与 SSR（或 SSG，静态站点生成）配合使用，无法独立存在。
传统 Vue（虚拟 DOM）是怎么 Hydration 的？
VDOM的Hydration是在首次挂载时，让Vnode认领页面上的DOM并恢复操作。
Vapor中没有VNode，我们如何去认领这些节点？
Vapor中的 Hydration
Vapor 的 Hydration 没有独立的 SSR 产物，CSR 和 SSR 共用同一份 setup() 代码。区别在于：CSR 时 template helper 执行 clone（新建 DOM），SSR 时执行 adopt（认领已有 DOM）。通过 isHydrating 标志来区分两种模式。
Hydration Cursor
Vapor 维护了一个 currentHydrationNode（水合游标），它像一个指针，指向“下一个待认领的 SSR DOM 节点”。template helper 执行时，直接认领游标指向的节点，然后把游标移到下一个逻辑节点。
跳跃的 Hydration Cursor
当遇到嵌套组件（如 <Foo />）时，游标需要“跳转”。进入子组件前，先保存外部“恢复点”（resume），再跳到子组件的起始位置；子组件处理完后，再恢复游标继续处理外层。
Hydration 期间的节点定位
Vapor 使用 logicalIndex（逻辑索引） 来定位节点，而不是依赖 DOM 的文本顺序。在 SSR 时，多根节点（如 Fragment）会被包裹成注释区间（ ... ）整体跳过，确保 CSR 和 SSR 的结构对得上。
复用 SSR comment 作为 anchor
Vapor 会直接复用 SSR 吐出的 注释节点，作为 v-if、v-for、slot 等动态片段的锚点（anchor），就像前面提到的那个永远留在 DOM 里的“书签”。
Hydration总结
在 Vapor Mode 中，Hydration 不再是“用虚拟 DOM 去比对真实 DOM”的消耗性操作，而是变成了一套“按编译时排好的顺序，用游标精准认领已有节点”的轻量流程。Vapor 通过“同源代码 + 游标定位 + 锚点复用”三管齐下，让 SSR 的激活过程比传统方式快得多，也简洁得多。
Vapor和VDOM在使用上的区别
Interop
Interop（互操作性）是软件工程中用于打通不同技术栈的通用概念。
在 Vapor Mode 中，它特指一套运行时桥接机制，让传统 VDOM 组件与新型 Vapor 组件能在同一应用中混用。因为同一个应用里可能同时存在VDOM和Vapor组件。
