Vue x Vite Conf 2026 总结
写在前面
作为一名仍在坚持古法编程的开发者，参加这次大会时，我内心有些忐忑。此行也是为了在风云变幻的AI浪潮中，如何重新找回作为小小前端工程师的信心与勇气。2026.7.18，在 Vue Conf 的会场上，我找到了答案。
我开始反思：一个已经停滞的技术人，还能继续向前吗？又该如何面对被 AI 席卷的世界？
尤大带来 Vue 与 Vite 的最新动向，Edison 拆解 Vapor Mode 从编译器到运行时的细粒度更新，黄玄让 Lynx 与 Vue 结合，使“Vue Native”从愿景走向现实，雪碧则在 8MB 内存内流畅运行 PocketJS。Vue Vapor 的每一步，都在证明：前端正朝着更底层、更高效、更跨界的方向重生。
那些在 Gemini 发布时高喊“前端已死”的人，和现在唱衰的大概是同一批，他们习惯在变革中选择固守。而真正的开发者，正像 shulaoda 那样打磨 Vite 与 Rolldown 的内存优化，像杨启明用 Weapp-vite 重构小程序工程化，像洛灵与 Neko 把 Vue 嵌入无 DOM 环境运行 Agent。这些探索，让每天写业务代码的我，也眼前一亮。 技术总结出自 Vue x Vite Conf 大会议程
技术与勇气，从来与完美无关，而在于动荡中持续重构自我。前端如此，人生亦然。
一、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组件。
三、Unlock Vue for Native by 黄玄
INFO
作为跨端开发经验不足的我，对Lynx其实是陌生的，我去查阅了一些资料，参考了vue-lynx官网、lynx4.0，总结出：
Lynx： 字节跳动推出的跨平台 UI 框架，底层用 C++ 实现，上层支持 JavaScript/TypeScript。它的定位类似于 React Native，但更强调双线程架构和原生性能。 2025年3月正式开源。
Vue Lynx ：让 Vue 3 开发者能用熟悉的 Composition API、ref、v-model 等语法，直接编写 Lynx 原生应用。它本质上是 Lynx 的 Vue 运行时适配层。
黄玄的在2026VueConf中的演讲偏向于Vue开发者能用Lynx做什么。
快速记录
✅ 附演讲地址：Unlock Vue for Native / 黄玄（Hux）
✅ 相关链接：Github仓库
Vue Lynx 的技术架构
传统 Web 模式的瓶颈：
Web 是“单线程”的：JavaScript 执行、DOM 计算、样式计算、绘制渲染，全部挤在 UI 线程的一帧（16ms）里。一个复杂的 Vue 组件，响应式更新 + Diff + DOM 操作可能就占了 10ms，剩下的 6ms 还要留给渲染，预算很容易爆。
React Native 模式也不行：Vue + VDOM 跑在 JS 线程，操作原生 UI 需要跨线程通信，每次通信都有序列化/反序列化开销。如果 UI 线程还要处理复杂的响应式逻辑，一条线程扛不住。
后台线程 + ShadowElement + ops批量提交：
这套架构让 Vue 的响应式系统能无感地跑在原生 UI 上，而不阻塞 UI 绘制。
把 Vue 的运行时（响应式、Diff、组件渲染）搬到“后台线程”去跑：UI 线程只负责执行 Element PAPI（创建视图、设置属性），不再被 Vue 的逻辑阻塞。
引入 ShadowElement（影子 DOM）：它是一棵“假的 DOM 树”，在后台线程里模拟 DOM 的结构和操作。当 Vue 要创建/更新节点时，它操作的是 ShadowElement，而不是真实的原生 UI。
批量提交（ops flat array）：所有对 ShadowElement 的改动，不会立即同步到 UI 线程，而是被收集成一个扁平的指令数组（ops），在每一帧（nextTick）批量发送给 UI 线程。UI 线程收到后，再“回放”这些指令，驱动 Element PAPI 更新原生视图。
事件回传：用户点击、滑动等事件从 UI 线程以“数字签名（sign）”的方式回传到后台线程，Vue 的回调函数仍然在后台线程执行。绕两条线程一个整圈，恰好就是一次 nextTick()。
WARNING
这个部分（后台线程 + ShadowElement + ops批量提交）我看得很吃力，我去找了黄玄和Lynx团队发表的《Lynx：迈向原生体验》，在文章里有更清晰的说明：
| 演讲中的概念 | 文章中的对应表述 |
|---|---|
| 后台线程跑Vue响应式 | “后台运行时（Background Runtime），作为用户代码的默认执行环境” |
| UI线程只做绘制 | “主线程运行时，独享同步UI操作权限” |
| ops批量提交 | “即IFR（首帧直出）机制的底层实现” |
| MTS（主线程脚本） | 演讲中演示的橡皮筋效果Sheet，正是MTS能力的体现 |
“房间里的大象”：vibe coding 与 AI 时代
这是演讲结尾最具哲学意味的部分，黄玄用“房间里的大象”（显而易见却没人敢提的问题）来引出：既然 AI 已经能写代码了，还要框架和 Lynx 干什么？
角色变了：过去，代码是人给机器的接口；现在，自然语言是人的接口，Agent 是执行者。框架的角色从“人的工具”变成了 AI 的 Harness（脚手架/约束环境）——它把无限的可能性压缩成可搜索、可推理、可生成的有限空间，让 AI 输出的代码更精准、更可靠。
最打动我的是尾声，黄玄说快乐不是消失了，而是转移了。过去的多巴胺来自“手写代码搞定一个 Bug”，现在的多巴胺来自“用自然语言准确描述需求，让 AI 精准实现”。我想，如果每天睡前都要跑一个 AI 任务才安心，那恰恰说明技术热情没有消退，只是换了一种形式。
四、❤️ PocketJS by 雪碧
INFO
雪碧大神的分享是整个Conf中我最喜欢的，非常有趣，听完我就想回去用PocketJS做个自推桌宠。这是大神在X上的分享PocketJS:零开销3D桌宠，简直太酷了！
PocketJ和Vue Vapor的关系：
PocketJS 是“舞台”：基于 Rust + QuickJS 构建的底层 UI 引擎，负责布局、渲染、内存管理。
Vue Vapor（以及 Solid）是“演员”：PocketJS 通过 Vue 官方提供的自定义渲染器接口（Custom Renderer API），让 Vue Vapor 的运行时能驱动 PocketJS 的 Rust 节点树。
雪碧在演讲中对比了三种框架在 PSP 上的每帧 JS 开销：Vue Vapor 2.1ms、传统 Vue 26.9ms、Solid 0.3ms。他强调的是 PocketJS 作为“容器”，对 Vue Vapor 的支持是“无删减接入”的，但 PocketJS 本身不是用 Vue 写的。
快速记录
✅ 附演讲地址：PocketJS 与 Vue Vaper 的嵌入式 GUI 探索 / 王译锋 （雪碧）
✅ 相关链接：Github仓库、看一些PocketJs的demo
基于帧的确定性时钟
Web 的“非确定性”问题：在浏览器里，requestAnimationFrame 的调度会受到浏览器标签页切换、后台任务、垃圾回收等影响，导致掉帧或执行顺序不一致。PPT 里举例说，同一个异步业务跑 60 次，浏览器可能因为调度抖动产生 22 种不同的结果——这就是 E2E 测试经常“偶发失败”的根源。
这是 PocketJS 架构中最核心、最具“游戏引擎”思维的创新。
PocketJS 的“帧折叠”解法：它像游戏引擎一样，强制每帧只执行一次确定性事务，公式是 state[n+1] = F(state[n], input[n])。这一帧里所有用户的输入（按键、定时器、网络回调）都被打包成一个 “磁带（the tape）”——这是外界进入系统的唯一入口。
效果：同样的“磁带”重放 60 次，系统状态永远只有 1 种确定结果。这意味着UI 状态机完全可预测、可回放、可精确复现 Bug，对自动化测试和 AI 调试是降维打击。
Demo 秀：从 Figma 到 YouTube 到 3D 射击游戏
Pocket Figma
把整份设计稿在构建期烘焙成瓦片集（CLUT8 调色板纹理），运行时按视口流式加载，显存占用被极致压缩。
Pocket YouTube（像素流送）
因为 PSP 的 WiFi 只有 100KB/s，无法直接播视频。雪碧给 PSP 插上 USB 转接头，连到 Mac，用 FFmpeg 在 Mac 端解码视频，将像素流通过 USB 持续推送给 PSP 渲染。他甚至调侃：“QuickJS 和 FFmpeg 的作者 Fabrice Bellard 应该没想过自己的两个作品能这样合体。”
OpenStrike 3D 射击游戏
详情可以参考《反恐精英的精神续作也能在PSP上玩了？！》。雪碧接用 PocketJS 的 pocket3d 渲染 BSP 关卡，生成 sceGu 显示列表，HUD 是 PocketJS 的 Vue 组件，并且通过 USB 连着 Mac 上的 DevTools，实时查看真机组件树——这对嵌入式开发来说简直是梦幻。
Session 才是比 Coding 更有价值的
PocketJS 本身是“AI Native”开发的——单人加一群 Coding Agent，雪碧公开了 59 个完整的 AI 开发 Session 档案，强调 “Session 才是比 Coding 更有价值的”。
他甚至说，现在正在用 AI 把 QuickJS“锈化成 Rust”（用 Rust 重写），这很难、烧了很多 Token，但把“写 JS 引擎时 Agent 到底怎么想”的过程分享出来，才是最有意思的。
这也许可以理解为，在 AI 时代，前端开发者的核心价值从“写代码”转向“描述意图、审阅计划、做架构决策”。因此，有意识地记录与 AI 的对话过程，将成为最宝贵的技术资产。
五、Nuxt 与模块联邦构建超级应用 by Néstor
快速记录
✅ 附演讲地址：使用 Nuxt 与模块联邦构建超级应用 - Néstor López
✅ 相关链接：Module Federation微前端架构、Github仓库、module-federation/vite、module-federation/nuxt、AI部署平台
模块联邦在做什么
TIP
这段演讲是全英文，听了太吃力，对于大多数日常工作场景比较遥远，我只能大致总结一下我理解的部分。Néstor想表达的核心应该是如何用 Nuxt 和 模块联邦 (Module Federation) 组合，来解决大型前端项目的协作和部署难题。
传统方式 (图左)：import Widget from "./Widget.vue" 是在构建时就确定的。一旦打包，Widget 组件就被固定了。
模块联邦方式 (图右)：const Widget = await loadRemote("checkout/Widget") 是在运行时动态加载的。指应用在浏览器里运行时，才去把各个独立部署的模块拼装起来，而不是在开发打包时就揉在一起。这就像乐高积木，可以在玩的时候随意替换其中一块。
他分享了电商公司不同开发团队，（如结账、购物车团队）能以各自速度独立开发、测试和部署，以此解决大型单体前端应用成为团队瓶颈问题。
六、TNB by Johnson
快速记录
✅ 附演讲地址：Vue 离 TypeScript 7 还有多远？ - Johnson
✅ 相关链接：typescript-native-bridge
Johnson的分享
微软用 Go 语言重写的新版编译器 tsgo（TypeScript 7.0），但我们现在用的一些常用前端工具链如vue-tsc、typescript-eslint、@vue/typescript-plugin等，它们的底层代码都是基于旧版 TypeScript 的 API 编写的。
如果我们把项目中的ts升级，项目会大奔溃。Johnson 的 TNB 就是来解决这个兼容性断裂层的。
虽然TS团队有望在7.1的版本修复这些问题，但Johnson还是没等就直接搞出来了，很强👍。
实现方式：TNB 这个 npm 包，完全复刻了经典 typescript 包的所有程序化 API（createProgram、getTypeChecker、transpileModule 等）。对于 vue-tsc 等工具来说，它看到的还是那个熟悉的 typescript 对象。它把旧版 TypeScript 的 API 调用，转译并传递给底层用 Go 写的 tsgo 编译器去执行。
七、关于Vite的相关演讲总结（Weapp-vite by 杨启明）
WARNING
关于Vite的演讲有三场：按照时间顺序分别是从社区贡献到 VoidZero：聊聊 Vite 和 Rolldown 的内存优化 - shulaoda、Vite Task 的缓存魔法 - 王驰、Weapp-vite 对小程序工程化的重新思考 - 杨启明。前两场偏向工具链底层（内存、缓存），是给整个 Vite 生态打基础的“地基工程”；第三场偏向业务落地（小程序），是把新工具能力转化成实际开发体验的“上层建筑”。
前两场的内容我听了之后，觉得离自己日常的业务场景确实有些远。当然这不代表它们不重要，恰恰相反，正是因为有了这些底层的性能突破，上层应用才能跑得更顺畅。
只是我目前对纯构建链优化的接触不多，所以没有深入消化。Weapp-vite 这种场景化的实践，对我来说更容易理解和产生共鸣。
以下Weapp-vite部分进行展开总结。
快速记录
✅ 附演讲地址：Weapp-vite 对小程序工程化的重新思考 - 杨启明
✅ 相关链接：weapp-vite、weapp-tailwindcss、《Vue 编译本质论》
它是什么？
Weapp-vite 的定位是一句简单的话：为原生微信小程序提供 Vite 工程化能力。
它的公式是：Weapp-vite = Vite + Rolldown + Vue + 原生小程序工程化增强
注意，它不是又一个跨端框架，不要求你把页面重写成 Vue 或 React。它的核心哲学是——把原生小程序作为一等资产，原生目录结构可以直接运行，可以渐进式混用，而非“推倒重来”。
几个让我觉得“有用”的功能
原生项目秒级接入
不管是新项目还是已有存量项目，都可以快速接入：
新项目：
npm create weapp-vite已有项目：
npx create-weapp-vite init
接入后不强制改页面，只补一个 weapp-vite.config.ts 和 dev/build 入口，原生页面原封不动就能跑起来。
npm 依赖自动构建与分发
这是原生小程序开发长期以来的痛点。Weapp-vite 把 npm 构建交给了 Rolldown：
组件库依赖（如 TDesign、Vant）→ 进入 miniprogram_npm
运行时依赖（如 lodash、dayjs）→ inline 进引用方产物
业务域依赖 → 可以按主包/普通分包/独立分包分发
开发者只需要正常 npm install，构建系统自动分析依赖形态并决定产物落位。不用手工区分每个包该放哪，不用额外维护 npm 构建目录，不用让团队记住依赖边界。
AI 复验闭环：@weapp-vite/mcp
这是我个人觉得最有前瞻性的功能。AI 改完代码后，可以直接调用 MCP 工具进入微信开发者工具自动复验，把日志、截图、视觉对比等证据回传给 AI。
流程是：AI 修改 → @weapp-vite/mcp 复验 → 证据回传。 这形成了一个完整的闭环，让 AI 编程不再停留在“生成代码”阶段，而是能自动验证运行结果。
另外，项目还提供了迁移 Skill，AI 可以按迁移手册盘点原生资产（app.json、页面、组件、分包、npm、插件等），然后自动接入 Weapp-vite.不改页面内容，只接工具链和项目入口。
八、❤️ markstream-vue by Simon He
快速记录
✅ 附演讲地址：你的 Markdown 渲染器，扛得住 AI 输出吗？ - Simon He
✅ 相关链接：markstream-vue、markstream文档、最强流式渲染没有之一 markstream-vue
直面痛点
Simon He 在 Vue Conf 上的分享，直面了一个 AI 时代前端的新痛点：模型输出越来越长、越来越快，浏览器的渲染能力反而成了瓶颈。
过去我们渲染 Markdown，是等全文到达后一次性解析和渲染。但 AI 是流式输出的——一个字一个字地往外蹦。传统做法是“每收到一段新内容，就把全文重新解析一遍，再重新渲染一遍，最后替换整个 DOM”。随着 AI 上下文从 8K 扩展到 1M+，内容长度增长了上百倍，再加上代码块、Mermaid 图表、KaTeX 公式这些“重型节点”，每次全量重渲染的成本高得惊人。
markstream-vue 的核心解法就是三个字：只处理变化的部分。
它为什么快？
1. 解析层（parser）：只解析“脏尾巴” :这是markstream-vue 和 markdown-it-ts 配合的关键。每次收到增量内容，解析器会先判断：前面哪些 token 是“稳定”的（已经完整，不会再变），哪些是“脏的”（还在持续输入中，比如一个没写完的代码块）。它只重新解析那段“脏尾巴”，前面已经完成的内容直接复用，不再重复解析。
2. Vue 渲染层：复用稳定节点 :解析出来的“稳定 token”，对应的 DOM 节点会被保留和复用。只有“脏尾巴”对应的那部分 DOM 才会被更新或替换。
3. 调度层（scheduler）:把更新拆到多帧 :浏览器每帧只有 16.7ms 的预算。如果一次更新要处理 100 个节点，markstream-vue 不会一次性塞满，而是拆成 10 帧，每帧只处理 10 个。这样滚动和输入就不会被打断，用户感知到的始终是“流畅的”，而不是“卡一下，然后突然蹦出一大段”。
九、Vue 生态里的 Agent 开发实践
WARNING
最后两场演讲我的总结是：AI Agent 开发中，前端工程师能做什么？ 并非我当前熟悉的领域，所以这里只做简要记录，不展开深入讨论。
| 夕阳针 | 洛灵 & Neko | |
|---|---|---|
| 切入点 | 开发 Agent Client 的体验 | 评测 Agent 行为的方法论 |
| 核心工具 | Vue 组合式 API、组件化 | Velium + Vieval + Vitest |
| 解决的问题 | 降低 AI 工具开发的心智负担 | 让 Agent 评测变得确定、可复现 |
| 相关链接 | 从 Yak Shaving 到 Agent：Vue 如何降低 AI 工具开发心智负担 | ⾃信地开发 Agent：把 Vue 和前端工具链融合到 Agent 里 |
在 AI 让代码生成变得越来越容易的当下，前端工程师的价值正在从“写 UI”转向“为 AI 构建可靠的基础设施”——包括更稳的渲染、更可控的 Prompt、更可信的评测。这或许就是“前端永生”的另一种注解。