模板编译与虚拟 DOM

• v-memo 接收依赖数组，依赖未变时跳过该子树更新
• 配合 v-for 缓存"几乎不变化"的列表项
• 更新粒度从"整组件"细化到"子树/节点"

v-memo="[depA, depB]" 声明该子树只在依赖数组变化时才重新渲染：依赖不变时，Vue 复用上一次创建的 VNode 子树，跳过 diff 与重建；依赖变化（或数组为空时恒更新）才重新创建。工程价值：当 v-for 列表中每项内部结构复杂、但只有少数项受某些状态影响时，v-memo 让更新粒度从"整个列表重新 diff"降到"仅依赖变化的项"，显著提升渲染性能——典型场景是"巨型表格中仅某行高亮/展开"，配合子组件 memo 化效果叠加。注意点：v-memo 的依赖数组必须穷举该项模板中用到的所有响应式依赖，漏写会导致 UI 不更新；它适合"结构稳定、依赖少而明确"的固定项，依赖频繁变化时收益消失且增加维护成本；与 v-once（彻底静态化）的区别是 v-memo 保留受控的动态能力。

本题考察"编译器时代码级优化指令"：v-memo 是手动声明"跳过条件"的优化手段。回答要点是"依赖数组决定是否跳过 + 适用场景（列表固定项）+ 依赖穷举纪律"，并对比 v-once 的静态化语义，说明收益与风险的边界。

• 事件修饰符（.stop/.prevent/.self/.once 等）编译为包装函数
• .capture/.passive 映射到 addEventListener 选项
• v-bind 的属性/事件/动态绑定区分（区分 isProp、事件前缀）

编译器对 v-on 的修饰符分两类处理：行为型修饰符（.stop、.prevent、.self、.once）被编译为包装函数（如 $event.stopPropagation()），在处理器内部执行；配置型修饰符（.capture、.passive）直接映射为 addEventListener 的选项参数，交给原生事件系统。v-bind 方面，编译器把绑定按目标分类：静态/动态属性绑定（含 class/style 的特判）、事件绑定（@）、以及通过 isProp 判断（如 :value 在 input 上按 prop 处理），产出带 PatchFlag 的 props 描述，diff 时按需更新。内联事件处理器默认通过 cacheHandlers 缓存（条件编译选项），同一模板位置的处理器对象复用，避免重复创建闭包——这也是"事件处理器不产生无谓更新"的编译保障之一。

本题考察模板编译对事件/属性绑定的规范化：修饰符的"包装 vs 选项"两分法、绑定的"prop/attr/事件"分类、以及缓存策略。回答时结合 PatchFlag 说明"哪些绑定被标记为动态"，体现对编译产物如何服务运行时更新的理解。

• v-once 一次性渲染，内容永不更新，彻底静态化
• v-memo 按依赖数组条件性跳过更新
• 静态内容比例高时的收益

v-once 把子树标记为"只渲染一次"：首次渲染后缓存 VNode，之后任何数据变化都不会触发该子树更新，适合纯静态内容（如版权区、一次性生成的模板片段），收益是彻底移除更新开销；代价是内容永不刷新，绑定其中的动态数据会停留在初始值。v-memo 是条件性跳过：依赖数组未变则复用子树，变化则正常更新，适合"大部分时候不变、偶尔变化"的内容（列表固定项、折叠面板内部）。取舍原则：内容确定静态用 v-once；内容偶变但结构重用 v-memo；两者都要求"明确知晓更新边界"，误用（v-once 包裹本应更新的区域、v-memo 依赖漏写）会造成难排查的 UI 不更新问题。性能敏感视图中二者是"最后一公里"的精细优化，应先用组件拆分、局部订阅等常规手段，再考虑指令级跳过。

本题考察两种"跳过更新"指令的定位差异：v-once = 无条件的静态化，v-memo = 有条件的缓存。回答时强调"更新边界认知"是使用前提，并建议优化次序（先架构优化再指令级优化），体现性能工程的优先级判断。

• 运行时编译模式下按模板字符串缓存编译产物
• 构建时预编译（vue-loader/vite 插件）完全避免运行时编译
• 编译缓存的 key 与缓存失效

模板编译缓存指运行时把"模板字符串 → 渲染函数"的编译结果缓存起来：使用完整版 Vue（含编译器）时，同一模板字符串只编译一次，后续复用（如动态组件反复渲染同一模板），避免重复编译开销；缓存以模板字符串为 key，String 规范化保证等价模板命中同一缓存。生产环境的主流做法是构建时预编译：vue-loader / @vitejs/plugin-vue 在构建期把 SFC 模板编译为渲染函数（含静态提升、PatchFlag 等优化），运行时不再需要编译器，因此产物更小、启动更快，这也是"运行时 + 编译器"包与"仅运行时"包区分的意义。SSR 场景同样预编译模板。缓存要点：运行时缓存适合开发调试与动态模板（template 选项字符串），生产应保证预编译路径，避免把编译器打进浏览器产物。

本题考察"编译发生的时机"：运行时缓存是"兜底与开发态"，构建时预编译是"生产正确姿势"。回答时对比两条路径的产物与性能差异，并说明 SFC 的模板天然走预编译、动态 template 字符串走运行时编译+缓存，即覆盖全貌。

• 性能对比必须基于目标场景与真实基准
• VDOM 的批量 diff 与 Vapor 的细粒度更新的适用边界
• 首屏、更新吞吐、内存等不同维度的差异

Vapor（无 VDOM 编译模式）把模板编译为细粒度 DOM 更新指令，更新时直接定位到变化的节点；VDOM 则先构建/比较虚拟树再批量 patch。两者各有适用场景：高频细粒度更新、超大列表局部变化时 Vapor 通常更优（无整树 diff、更少分配）；结构复杂且更新集中在少数组件时，VDOM 的编译优化（PatchFlag、静态提升）可能已足够且更成熟。因此正确姿态是"基于目标场景设计基准、以实测数据说话"：基准需覆盖首屏加载（产物大小、解析执行）、局部更新吞吐、长列表滚动（FPS/INP）、长时间驻留（GC 暂停、retained heap、内存增长）等维度，并在真实设备/浏览器上采集，而非依赖单一 micro-benchmark 下结论。工程上还需考虑生态兼容（Vapor 实验性、第三方库 VNode 依赖）与迁移成本，性能只是决策因素之一。

本题考察性能工程的方法论：对比必须"场景化 + 实测化"。回答应给出基准设计维度（首屏、更新、滚动、内存）与指标（FPS、INP、GC、retained heap），并承认两种方案各自的优势边界，避免"Vapor 一定更快"的绝对结论——这正是题目预设的考察意图。

• SSR 编译输出面向字符串拼接/流式渲染，客户端面向 VNode 与事件绑定
• hydration 复用服务端 HTML，仅绑定事件与激活响应式
• 编译器对 SSR 特有指令（如 useId、teleport）的处理

SSR 阶段编译器产出的是"渲染为字符串"的代码路径（SSR 渲染函数），直接拼接 HTML，无 VNode 创建与 diff；客户端编译器产出标准渲染函数，负责创建 VNode、绑定事件并挂载响应式。hydration 阶段客户端不再重新创建 DOM，而是遍历服务端 HTML 与本地 VNode 树做对齐匹配、绑定事件与响应式关系，编译器为此提供水合友好的产物（如跳过静态节点检查、特殊属性处理），并对 useId 等 SSR 特有能力生成确定性值。对首屏的影响：SSR 减少客户端"首次 DOM 构建 + 数据请求"的等待（TTFB 后直接可交互骨架），但 HTML 字节量与序列化 payload 增加传输成本；hydration 的"注水"耗时与页面复杂度正相关，编译器优化（静态节点跳过、v-memo）与流式渲染（Suspense 分块）可降低可交互时间（TTI）。生产实践常用 Nuxt 的自动优化，把"静态内容服务端输出、动态部分客户端激活"结合。

本题考察"一套模板、两条编译路径"的认知：SSR 产物面向字符串、客户端产物面向 VNode、hydration 是"复用 + 激活"。回答时把三者的差异与首屏指标（TTFB、FCP、TTI、字节量）关联起来，说明编译器优化如何影响水合成本，即构成完整回答。

• Block 的开启（openBlock）与闭合（closeBlock）生成
• 动态子节点收集进 dynamicChildren 的扁平化数组
• v-if/v-for 分支作为子块的嵌套与切换

编译器在遇到"动态结构入口"时生成 openBlock()/closeBlock()：块（Block）是虚拟 DOM 树中"动态部分"的收集单元，块内的动态节点（带 PatchFlag）被扁平化加入 dynamicChildren 数组，更新时直接遍历该数组而非递归整树。v-if 指令编译为条件块：每个分支（含 包裹的分支）是独立的子块，条件切换时替换子块并重建其 dynamicChildren；v-for 同样产生块，迭代生成的每个子项是动态子树，其内层再按需开块。块的边界规则：块从"组件根或带动态结构指令的节点"开始，动态子节点无论嵌套多深都被收集到所属块的 dynamicChildren（收集是递归的、按块扁平化）；静态节点不进数组。边界价值：块机制让"更新成本与动态节点数成正比"，与页面静态规模解耦，是 Vue 3 高性能更新的核心；模板写法上 仅作结构容器不影响块边界。

本题考察 Block Tree 的实现细节：openBlock/closeBlock 是编译产物中的运行时标记，dynamicChildren 是扁平化收集结果。回答要点是"块 = 动态收集单元、v-if/v-for 分支 = 子块、收集范围 = 块内所有动态节点"，能说明与整树 diff 的成本差异即为掌握。

• defineModel 展开为 modelValue prop 与 update:modelValue emit
• 三者在编译产物中的 props/emits 配置合并
• 静态属性（无动态绑定的 attr）的编译处理与继承

编译产物层面，defineModel() 会展开为 props 配置中的 modelValue（及 type/required/default 转换）与 emits 中的 update:modelValue，与显式 defineProps/defineEmits 声明的配置合并进同一份组件选项；命名模型（defineModel('a')）对应 a/update:a。defineProps/defineEmits 则完全由开发者声明 props 与事件契约。静态属性的取舍：模板中无动态绑定的属性（如

本题考察"宏的编译等价性"与"静态/动态属性分流"：defineModel 是 props/emits 的语法糖，编译后统一；静态属性自动提升、动态属性进 diff 路径。回答时把两层（宏展开合并、静态属性编译）讲清，并给出选择建议（简单双向绑定用 defineModel、复杂契约用显式声明）。

• shapeFlag 用位标志描述 VNode 类型（元素、组件、Fragment、文本等）
• 位与/位或运算快速判定类型，替代字符串比较
• PatchFlag 同样基于位运算标记动态内容

shapeFlag 是 VNode 上的一组位标志，编码节点类型信息：ELEMENT（1）、FUNCTIONAL_COMPONENT、STATEFUL_COMPONENT、TEXT_CHILDREN、ARRAY_CHILDREN、SLOTS_CHILDREN、TELEPORT、SUSPENSE、COMPONENT_SHOULD_KEEP_ALIVE 等，按二进制位分配。类型判定用位运算：如 isComponent = shapeFlag & ShapeFlags.COMPONENT，组合属性（既是组件又有插槽子节点）用位或编码，运行时通过位与快速分派渲染/更新分支，避免字符串或多次属性比较。PatchFlag 同理以位标志标注"动态类型"（TEXT、CLASS、STYLE、PROPS、FULL_PROPS 等），diff 时位与检查决定更新策略。工程价值：类型与更新策略的判定从"条件链"变为"常数时间位运算"，配合编译器预计算标志，显著降低高频更新路径的分支开销，是 Vue 3 运行时性能的基础设计之一。

本题考察 VNode 的"标志位设计"：shapeFlag 编码类型、PatchFlag 编码更新需求，位运算提供常数时间判定。回答时给出典型位运算示例（isComponent、组合标志）并说明与编译器（预计算）的分工，即体现对运行时数据结构的理解深度。

• 四类优化的各自职责与实现
• 动静分离的编译策略
• 更新成本与节点规模解耦

这四类优化构成 Vue 3 编译器的"动静分离"体系：静态节点提升（hoisting）把不依赖响应式的节点与 props 移出渲染函数，复用同一对象；缓存（cacheHandlers）缓存内联事件处理器等函数引用，避免每次渲染创建新闭包；PatchFlag 为动态绑定标注更新类型，diff 按位检查只更新必要部分；Block Tree 把动态节点扁平化收集到块数组，更新时直达目标。组合效果：渲染函数的静态部分"一次创建、反复复用"，动态部分"精准定位、最小更新"——更新成本从"与模板规模成正比"变为"与动态节点数成正比"，同时减少每次渲染的分配与 GC 压力。工程价值体现在高频更新场景（表格、列表、实时数据）、复杂页面首屏后交互流畅度，以及大规模列表的滚动性能；开发者无感知地获得收益，且这些优化与 v-once/v-memo 等手动手段可叠加。

本题是编译优化体系的综述题：回答应逐一说明四项优化的机制，再归纳"动静分离"的统一设计目标（降低更新与分配成本），并落到实际场景收益。能点出"编译器自动完成、开发者零成本受益"与"与手动优化叠加"即为完整。

• 编译器对 SSR/水合友好的产物生成（静态节点标记、注释锚点）
• 常见 mismatch 成因（动态内容、浏览器差异、随机值）
• 开发模式的水合警告与排查

Vue 3 的 SSR 渲染函数与客户端 hydration 共享同一模板编译：服务端输出含注释锚点（用于水合时对齐位置）的 HTML，客户端水合时遍历服务端 DOM 与本地 VNode 树逐节点匹配，编译器对静态节点生成确定性结构、对动态节点生成水合分支，减少对齐歧义。避免 mismatch 的要点：渲染输出必须"服务端 == 客户端首次渲染"，因此应规避——依赖 window/localStorage/Date 的随机内容、浏览器差异（如大小写、空属性、无效 HTML 的浏览器修正）、仅客户端初始化的状态；开发模式下 mismatch 会产生带建议的警告（提示在 onMounted 中处理客户端专属内容或用 useId 生成稳定 ID）。v-html 内容服务端与客户端一致即可，动态组件、Teleport、Suspense 均有各自的水合规则；生产实践用 Nuxt/插件自动规避常见陷阱（如 hydration 专用组件）。

本题考察水合的"一致性原则"：编译产物两边同源，mismatch 多来自"渲染输入的运行时差异"。回答时先讲编译器如何支撑（锚点、同源产物），再讲业务侧的 mismatch 成因与排查（警告、onMounted 隔离、useId），体现"编译机制 + 业务纪律"双重视角。

• parse：模板字符串 → AST（词法/语法分析）
• optimize：静态标记（Vue 2 的 markStatic / Vue 3 的转换插件）
• generate：AST → 渲染函数代码字符串

Vue 的模板编译管道分三段：parse 阶段用正则/扫描器把模板字符串解析为 AST（抽象语法树），节点携带类型、属性、插值表达式等信息，并处理指令、插槽、注释等结构；optimize 阶段分析 AST 做"静态标记"（Vue 2 标记静态子树以便更新时跳过；Vue 3 改为转换插件体系，对 AST 做静态提升、PatchFlag 标注、事件缓存、块收集等各类转换）；generate 阶段遍历处理后的 AST，生成渲染函数代码（字符串），运行时通过 new Function 或直接执行得到渲染函数。Vue 3 的编译器架构以"转换插件"为扩展点：每个优化是一个可组合的 transform 函数（transformElement、transformExpression、hoistStatic 等），编译选项可插拔，这也是 Vapor 编译模式与自定义指令编译的基础。三段协同实现"模板 → 优化决策 → 高效运行时代码"。

本题考察编译管道的基础模型：parse 建结构、optimize 做决策、generate 产代码。回答时说明 Vue 3 对 optimize 阶段的"插件化改造"（transform 体系）及 Vapor 如何复用该架构，能对比 Vue 2 的静态标记与 Vue 3 的 PatchFlag/提升策略即为深入。

• Svelte 5 Runes：以 runes（$state/$derived/$effect）统一显式响应式声明
• Vapor：复用 Vue 响应式内核，编译为细粒度 DOM 更新
• 两者都免虚拟 DOM，但响应式模型与更新路径不同

两者都采用"编译时优化 + 无虚拟 DOM"的路线，但响应式模型不同。Svelte 5 引入 Runes 替代旧编译时魔法：用 $state、$derived、$effect 等"runes"（编译器识别的符号）显式声明响应式变量，编译器据此生成细粒度依赖与 DOM 更新指令，运行时是组件级信号系统；其响应式语义由 Svelte 编译器专有实现。Vapor 是 Vue 的编译模式：模板编译为细粒度 DOM 更新指令（免 VNode），但响应式内核仍是 Vue 的（ref/reactive/computed/watch 与 alien-signals 集成），编译只决定"更新怎么落地"，API 心智与现有 Vue 组合式 API 一致。取舍：Svelte 5 是"语言/运行时一体"的完整方案，Runes 改变了写法但体验统一；Vapor 是 Vue 内部的"可选渲染后端"，对既有 Vue 代码迁移成本低、可混合，但实验性且生态（组件库 VNode 依赖）需适配。性能上都追求最小更新路径，实际差异需按场景实测。

本题考察两种"编译时响应式"范式的差异：Svelte Runes 改变声明方式（runes 语法 + 专有运行时），Vapor 保留 Vue 响应式 API（只换渲染后端）。回答时抓住"响应式模型归属（谁实现信号）"与"迁移成本（新范式 vs 可选模式）"两个维度对比，即为核心。

• cloneVNode 克隆 VNode（浅克隆 + 保留 slot/children 引用）
• mergeProps 合并多个 props 对象（class/style 合并、onXxx 事件数组化）
• 在渲染函数、组件库封装中的应用

cloneVNode(vnode, extraProps) 浅克隆一个 VNode 并可选覆盖 props，克隆保留原节点的 type、children 引用（不深度克隆），用于"复用结构、替换数据"的场景——如组件库中根据状态派生不同渲染配置、v-for 中复用同一模板节点、动画/过渡包装时保留原节点语义。mergeProps 把多个 props 对象合并为一个：class/style 智能合并（而非覆盖）、同名事件（onXxx）合并为数组依次调用、其余属性后者覆盖，避免手写合并逻辑的坑。工程价值：在渲染函数（h()）与高阶组件封装中，cloneVNode 保证节点身份与结构复用（配合 v-model/事件透传），mergeProps 保证属性与事件的正确合并（如同时透传父组件 props 与内部默认 props），是组件库与动态渲染代码的基础工具；注意 cloneVNode 是浅克隆，修改 children 需要显式替换。

本题考察 VNode 层面的工具 API：cloneVNode 是"结构复用 + 数据替换"，mergeProps 是"属性/事件智能合并"。回答时给出典型场景（渲染函数、封装组件透传、事件合并），并点明与对象展开（{ ...a, ...b }）在 class/事件合并上的本质差异，即达到掌握。

• 静态提升：不变的节点/props 提到渲染函数外复用
• 预字符串化：连续静态节点合并为单个字符串节点
• 两者触发条件与收益

静态提升（Static Hoisting）把渲染函数中不依赖响应式的节点、属性对象、插值表达式结果提升到函数作用域外（每次渲染复用同一对象），避免每次渲染重新创建 VNode 与对象，减少分配与 GC；连续、纯静态的兄弟节点会被"预字符串化"（Pre-stringification）：编译器把它们合并为一个文本字符串节点（createStaticVNode），渲染时整段作为 innerHTML 一次性写入，彻底跳过逐节点 VNode 创建，尤其适合大量静态结构（如长文档片段、表格静态列）。两者都由编译器自动判定（静态 = 无响应式依赖、无指令副作用），与动态部分共存时，动态节点仍走 PatchFlag/块收集路径。工程价值：静态内容占比高的模板，更新与创建成本大幅下降；配合 v-once 可把"逻辑上静态"的子树显式交给编译器处理。

本题考察静态化优化的两个层次：对象级（提升复用）与节点级（字符串化整段写入）。回答时说明触发条件（纯静态）、收益（少分配、少创建、少 diff）以及预字符串化"一次性 innerHTML"的机制，即覆盖要点。

• Vapor 是无虚拟 DOM 的编译模式，直接生成细粒度 DOM 更新
• 复用 Vue 响应式内核与模板语法
• 实验/beta 状态、opt-in 启用、逐步开放

Vapor Mode 是 Vue 的编译策略：模板不再编译为"渲染函数 + VNode diff"，而是编译为直接的 DOM 创建与细粒度更新指令（按响应式依赖逐点更新），运行时无需虚拟 DOM 与 diff，减少中间对象与更新开销。它复用 Vue 现有的模板语法与响应式系统（ref/computed/watch），开发者 API 体验不变，仅渲染后端不同。能力边界：官方仍将其标记为实验性/beta，需在构建配置中 opt-in 开启（按组件或按构建粒度），支持面逐步扩大；当前不支持 Options API（组合式 API 是 Vapor 的目标形态），依赖 VNode 运行时契约的能力（如部分第三方组件库、Vue Test Utils 的部分 API）需要适配或隔离；官方策略是"混合共存"——Vapor 组件与普通组件可在同一应用中协作，不要求整体迁移。启用前应评估组件库兼容性，用灰度与回滚方案控制风险。

本题考察 Vapor 的定位与边界：它是"编译产物革命"而非"框架重写"，实验性体现在生态适配与能力覆盖，而非技术不成熟。回答时讲清"免 VDOM + 复用响应式 + opt-in 混合 + Options API 限制"四点，即完整刻画现状。

• composedPath() 返回事件传播路径（含 Shadow DOM 穿透）
• composed 事件（click 等）跨 Shadow 边界的传播
• Web Components 与 Vue 事件委托的协作

composedPath() 返回事件当前传播经过的 DOM 节点数组，与 composed 标志配合能穿透 Shadow DOM 边界：即使事件监听器绑定在宿主元素或文档上，也能通过 composedPath() 获知事件真正发起的 Shadow 树内部节点，从而正确判断"点击了哪个内部元素"；非 composed 事件（如部分自定义事件）则停留在 Shadow 边界内。工程价值：在 Vue/框架事件委托或 document 级监听中，用 composedPath() 实现基于"实际目标"的判定（如点击外部关闭弹层时识别 Shadow 内部元素），避免事件目标被 Shadow 边界屏蔽。边界：SSR 阶段服务端只输出 HTML 字符串，不创建 Shadow DOM 与自定义元素，Shadow 结构在客户端由组件（如 Vue Web Components 或自定义元素）挂载时创建，因此水合时的事件路径以"客户端构建后的真实 DOM"为准，SSR 期间不涉及 composedPath 相关行为——这要求依赖 Shadow DOM 的交互逻辑只在客户端生效。

本题考察 Shadow DOM 事件模型与 SSR 的边界认知：composedPath 解决"跨边界定位真实目标"，SSR 则"没有 Shadow"（服务端无 DOM）。回答时把事件穿透机制与"Shadow 由客户端创建"的时序差异分开讲，即覆盖要点。

• 模板中 ref 自动解包（直接使用 ref 名，无需 .value）
• reactive 对象的属性在模板中直接访问
• 响应式重构（版本计数/链表）带来的性能与稳定性

模板编译与渲染上下文对 ref 做自动解包：顶层 ref 在模板中直接用变量名访问（{{ count }} 而非 {{ count.value }}），数组与对象中的 ref 在模板表达式内也自动解包（仅限顶层属性），这让模板代码简洁且不易误写。reactive 对象本身在模板中直接按属性访问。Vue 3.5+ 的响应式重构（版本计数 + 双向链表依赖管理、alien-signals 集成）从实现层提升了这种解包后的更新效率：更精确的依赖追踪、更低的分配开销，使"模板即响应式"的日常写法在高频更新下依然高效。工程价值：模板语法的心智成本低（不需要区分 ref/reactive 的访问形态），响应式细节被框架收敛，开发者专注状态建模；边界提醒：自动解包仅作用于渲染上下文的顶层，解构后需显式 toRefs，且在 JS 逻辑中必须使用 .value。

本题考察"模板自动解包"与"内核重构"的衔接：解包是渲染层语法便利，重构是运行时效率保障。回答时先讲解包规则（顶层 ref、数组/对象顶层属性），再讲重构如何让这种便利无性能代价，最后点明 JS 侧 .value 的边界。

• 内联事件处理器的编译产物与闭包捕获
• cacheHandlers 缓存机制避免重复创建函数
• 闭包泄漏的真实成因（长生命周期持有短生命周期引用）

事件绑定本身不会因"闭包"泄漏：@click="fn" 绑定的是引用；@click="count++" 这类内联语句会被编译为包装函数，其中捕获渲染作用域的变量。编译器默认启用 cacheHandlers 时，同一模板位置的内联处理器被缓存复用（首次创建后不再重建），函数不会随每次渲染重新创建；即使每次重建，只要监听器随 DOM 一起被移除（组件卸载、v-if 切换），也不会泄漏。真正可能的泄漏来自"长生命周期对象持有短生命周期引用"：如在全局/模块级闭包中保存了组件作用域变量、或手动 addEventListener 未在 onUnmounted 移除、或第三方实例未销毁——这些与 @click/:click 语法无关，属于资源管理问题。判断方法：DevTools 内存快照对比（卸载前后 retained 对象）、性能面板的"函数分配"统计；规避：监听资源统一在卸载钩子清理、避免把组件状态写入模块级闭包、配合 cacheHandlers 关闭不必要的函数重建。

本题考察"内存泄漏归因"：事件绑定编译产物本身是安全的（缓存 + DOM 移除即回收），风险来自资源生命周期管理。回答时区分"函数重复创建"（性能问题，cacheHandlers 缓解）与"闭包持有"（泄漏问题，手动监听与全局引用造成），并给出排查工具，即体现正确的归因能力。

• 函数式组件：无状态、无实例，渲染函数直接执行
• 内联组件：模板中直接使用组件对象字面量
• 编译器对内联组件的处理（每次渲染新对象导致的卸载/重建）

函数式组件（Functional Component）以函数定义、无组件实例与响应式上下文，渲染开销低：Vue 3 中可通过函数组件返回 VNode（props 作为第一参数），其编译产物不经过组件实例化路径，适合纯展示、高频切换的轻量场景；缺点是失去实例能力（无生命周期、无状态，需借助 setup 相关能力时受限）。Inline Component（内联组件）指模板中直接内联组件定义对象（如 或内联对象），编译器与运行时按组件处理，但每次渲染若生成新的组件对象，会导致旧组件卸载、新组件挂载的反复，破坏状态与性能。优化路径差异：函数式组件走"轻量函数调用"路径（少实例化开销）；内联组件应避免"每次渲染创建新对象"，应把组件定义提取为稳定引用或使用 resolveDynamicComponent 缓存。工程建议：高频轻量展示用函数式组件，动态组件用稳定注册的组件名/对象，避免内联字面量。

本题考察两类"轻量组件形态"的编译与运行时差异：函数式是"无实例的轻路径"，内联是"易被重建的陷阱"。回答时分别说明各自的编译/运行行为，重点指出内联组件对象不稳定引用的危害与规避，即构成完整回答。

• defineAsyncComponent 的 loader 被构建工具转为动态 import 代码分割
• 异步组件的加载/错误/超时状态配置
• Suspense 聚合异步依赖的加载态

defineAsyncComponent(() => import('./Heavy.vue')) 的 loader 会被 Vite/webpack 识别为动态 import，构建时把该组件拆分为独立 chunk，仅在首次渲染时通过网络加载，实现"路由级/组件级代码分割"——首屏只加载必要代码，其他按需下载。defineAsyncComponent 支持配置 loadingComponent、errorComponent、delay、timeout、onError（重试策略），管理加载过程的各状态。与 Suspense 配合：Suspense 边界内的异步组件（无论是否 defineAsyncComponent）在加载期间统一渲染 fallback，多个异步依赖聚合等待，避免每个组件各自闪现 loading；Suspense 解析失败的错误仍需组件级 errorCaptured 处理。工程价值：大体积第三方库、低频页面、编辑器等重组件用异步组件 + Suspense 实现"按需加载 + 统一骨架屏"，显著改善首屏与交互性能；注意配合合理的 chunk 拆分（动态 import 分包）与预加载策略（prefetch）。

本题考察"代码分割 + 加载状态管理"的协作：动态 import 解决字节量，defineAsyncComponent 解决状态机，Suspense 解决聚合展示。回答时把三层（构建产物、组件配置、Suspense 协调）串起来，并给出应用场景与收益，即为核心。

• v-pre 跳过编译直接输出原始模板内容
• v-once 一次性渲染，编译为静态化节点
• v-memo 条件性跳过更新

三者的静态化语义：v-pre 让编译器跳过该元素的模板编译，原样输出其内容（适合展示大量原始模板文本/标签，如文档示例），服务端同样原样输出；v-once 把子树编译为"仅渲染一次"的静态节点（Vue 3 中结合静态提升直接生成静态 VNode/字符串化节点），SSR 输出为一次性静态 HTML；v-memo 声明"依赖不变则复用"，其 SSR 输出与普通模板一致（静态化是运行时的跳过，SSR 只渲染一次无差异），价值在客户端更新阶段。与 Nuxt SSR 协作：静态化指令减少客户端水合/更新的工作量——v-once 的内容客户端激活时按静态处理，v-memo 的固定项在交互中跳过 diff；Nuxt 的静态分析与组件预渲染（如 prerender）结合时，这些指令让"基本静态的页面"服务端输出后客户端几乎零更新成本。注意 v-pre/v-once 的"过期内容"风险（绑定数据不更新），SSR 下两者输出的静态文本在客户端也不刷新，需按业务确认。

本题考察静态化指令在 SSR 语境下的分工：v-pre 是"不编译"，v-once 是"只渲染一次（含 SSR 输出）"，v-memo 是"条件跳过（客户端为主）"。回答时分别讲清语义、SSR/水合表现与"陈旧内容"风险，即覆盖协作全貌。

• key 在 diff 中标识节点身份，决定复用/移动/重建
• 无 key 时的就地复用（patch 同位置）导致的错位
• 编译器对 key 缺失的提示与 v-bind:key 的处理

v-for 列表中 key 是 diff 算法的"节点身份标识"：更新时按 key 匹配新旧节点，判断哪些复用、哪些移动、哪些删除，从而保持组件状态（输入框内容、滚动位置、展开状态）与 DOM 身份。缺少 key 时 Vue 采用"就地复用"策略：按索引位置对齐新旧节点并原地打补丁，当列表顺序变化（插入、删除、排序）时，节点内容与 DOM 位置错位——表现为输入内容串行、动画错乱、状态张冠李戴。编译器层面：模板的 v-for 必须显式提供 key 才会在渲染函数中生成带 key 的循环（key 通过 :key 绑定传入）；官方 lint 规则（vue/require-v-for-key）在构建期即拦截缺失。正确选择：key 应是数据中唯一且稳定的字段（业务 id），避免使用数组 index（插入/删除会错位）或随机值（导致每次重建、性能差且状态丢失）。

本题考察 diff 的身份识别机制：key 决定"复用或重建"的策略，缺失时索引对齐造成错位。回答时先讲 key 的机制与后果，再讲编译/构建期的校验，最后给选择原则（唯一稳定、避免 index/随机），即完整覆盖。

• Teleport 编译为 Teleport 类型 VNode，携带目标选择器
• 挂载时把子树渲染到目标 DOM 而非父级位置
• 虚拟树中的位置与真实 DOM 位置分离

模板中的 被编译为 Teleport 类型的 VNode，target（to）在运行时解析为真实 DOM 容器。挂载阶段，Teleport 把其子树创建到目标容器内，而非组件的 DOM 层级中——虚拟 DOM 树中的位置（逻辑父子关系）与真实 DOM 位置（渲染位置）分离。边界：Teleport 子树的组件上下文（provide/inject、作用域插槽、props 传递）仍属于原组件树，事件冒泡沿真实 DOM 冒泡到目标容器所在文档层级（可穿透回 Vue 组件树），样式继承随真实 DOM 位置变化（脱离父级 overflow/层级约束，但也脱离父级样式作用域）。虚拟树层面，Teleport 子树作为块的子节点参与更新收集；SSR 中 Teleport 内容输出在目标位置（需服务端目标存在或配置）。工程应用：Modal、Dropdown、Toast 挂到 body 解决层级与裁剪问题，同时保留组件上下文。

本题考察 Teleport 的"双位置"模型：虚拟树位置（逻辑）与真实 DOM 位置（渲染）解耦。回答时说明编译产物（Teleport VNode）、挂载行为（渲染到目标）、上下文保持（provide/inject 不变）与事件/样式随真实 DOM 的边界，即完整。

• Vue 2 VNode：tag/data/children/text/elm 等字段，无编译优化元数据
• Vue 3 VNode：shapeFlag 位标志、patchFlag、dynamicChildren、transition、key 等
• 编译器与运行时协作的元数据设计

Vue 2 的 VNode 以 tag、data、children、text、elm、key 等字段描述节点，diff 是全量递归比较，缺乏编译期元数据。Vue 3 的 VNode 面向"编译优化 + 运行时高效"重新设计：shapeFlag 用位标志编码节点类型（元素/组件/Fragment/Teleport/Suspense 及子节点形态），patchFlag 标注动态更新类型（TEXT/CLASS/PROPS 等位组合），dynamicChildren 由块机制收集的动态子节点数组（更新直达），transition 字段携带过渡上下文，key 保持节点身份标识；静态节点/静态 props 经提升与字符串化直接复用。差异的本质：Vue 2 的 VNode 是"渲染结果的描述"，Vue 3 的 VNode 是"带优化指令的执行计划"——编译器把"更新策略"预计算进数据结构，运行时按位决策，从而把 diff 成本降到与动态节点数成正比。此外 Vue 3 用 Fragment 替代多根/多文本节点，用 Suspense/Teleport 专属类型支持内置组件，能力边界更清晰。

本题考察 VNode 数据结构的演进：核心差异是"编译器元数据的有无"（patchFlag/shapeFlag/dynamicChildren）。回答时逐字段对比并归结到"预计算优化指令"的设计思想，说明其如何支撑 Vue 3 的高性能更新，即为核心。

• cacheHandlers 缓存模板中内联事件函数，避免每次渲染重建
• 缓存对 props 比较与子组件更新的影响
• v-once 的整体静态化语义

cacheHandlers（Vue 3 默认开启的编译优化）把模板中内联事件处理器（如 @click="count++"）的创建缓存起来：同一位置的处理器函数首次渲染创建后复用（绑定参数仍按需解析），避免每次渲染生成新闭包，从而减少 props 变化触发的子组件无谓更新与 GC。v-once 则把整个子树标记为"仅渲染一次"，是范围更大的静态化（内容不再随数据更新）。现代取舍：绝大多数场景依赖 cacheHandlers 的自动缓存即可——事件处理器稳定、子组件更新被正确触发；v-once 用于"确知子树永久静态"的内容（纯展示片段），收益是彻底免更新；v-memo 用于"大部分时间不变但偶尔更新"的子树，是 v-once 的柔性版本。原则：先让编译器自动优化（cacheHandlers、静态提升），仅在实测瓶颈与明确静态语义处使用 v-once/v-memo；v-once 误用（内容本应更新）会造成难排查的陈旧 UI。

本题考察"自动缓存 vs 显式静态化"的分层：cacheHandlers 是编译器默认行为（函数级），v-once 是开发者声明（子树级）。回答时说明 cacheHandlers 的机制与默认开启状态，再对比 v-once/v-memo 的适用边界与误用风险，即构成完整的取舍分析。

• 解构变量编译为基于 props 的响应式引用
• 与 toRefs(props) 的等价性
• 类型推导与默认值处理

在

本题考察 SFC 宏的编译产物细节：解构是"编译期转换"而非运行时魔法，等价于 toRefs。回答时讲清转换机制、类型与默认值支持、以及单向数据流约束保持不变，即完整覆盖。

• Vue v-bind 对象展开为 props 绑定，含 class/style/事件合并规则
• React JSX 展开是"创建时"的静态合并，对象变化需重新渲染
• Vue 对对象内动态 key 的响应式追踪

Vue 中 v-bind="props" 把对象整体绑定到组件/元素：对象内的键在模板编译期生成 props 描述，class/style 走合并逻辑（与显式 class 共存）、onXxx 事件参与事件合并，对象属性变化通过响应式系统追踪（对象是响应式时，属性更新触发组件更新并重新绑定）。React 中 <Component {...props}> 是 JSX 展开语法，在创建元素时把 props 对象键合并进元素描述，React 不关心对象的响应性——props 对象变化本身不会触发渲染，需要父组件状态更新驱动重渲染；事件以 onXxx 属性形式传递且无合并语义（后者覆盖前者），class 用 className 直接覆盖。差异本质：Vue 的绑定是"模板编译 + 运行时响应式"（动态绑定天然响应），React 的展开是"表达式求值"（依赖渲染周期）；Vue 自动处理合并与透传（attrs），React 需显式透传或自定义合并。工程上：Vue 用 v-bind 做条件绑定/批量透传较自然，React 需注意展开对象的引用稳定性与显式合并。

本题考察两大框架"绑定展开"的语义差异：Vue 偏声明式（编译 + 响应式追踪 + 合并规则），React 偏命令式（表达式求值 + 渲染驱动）。回答时从响应性、合并语义、透传机制三个维度对比，即为核心。

• SSR 序列化与 payload 的边界（只序列化必要数据）
• 渲染函数在服务端的执行与客户端不共享实例
• 编译器对组件渲染路径（SSR vs 客户端）的产物分化

SSR 与水合是两个独立进程/环境：服务端用 SSR 专用渲染函数把组件渲染为字符串，客户端用标准渲染函数创建新的组件实例并水合到该 HTML——两边互不共享响应式实例，响应式对象本身（Proxy 代理、组件实例）不会跨环境传递。会"泄漏"的是数据：服务端把渲染所需数据序列化进 payload（Nuxt 的 useFetch/useAsyncData payload、Vue 的 SSR 上下文），客户端水合时反序列化恢复状态；编译器在此的作用是产物分化——SSR 渲染路径（ssrRender 函数）不创建响应式实例、不绑定事件，只输出字符串，从根本上避免"服务端实例进入客户端"。工程注意：序列化只应包含纯数据（可 JSON 序列化），函数、代理、Date 等需转译或排除；避免把响应式状态写入 window 全局（会造成重复/陈旧数据与 XSS 风险）；编译器对 useId 等 SSR 能力生成确定性值，保证两边一致。

本题考察 SSR 环境的隔离模型：响应式实例不跨环境，只有"序列化数据"跨环境。回答时讲清双渲染路径（ssrRender vs render）、payload 序列化边界与安全注意（不序列化函数/代理、不污染 window），即完整。

• v-if 编译为条件渲染分支，切换时创建/销毁节点
• v-show 编译为 style display 切换，节点常驻 DOM
• 编译产物差异（分支 VNode vs 指令样式绑定）

v-if 在编译期生成条件分支：条件为真时创建并挂载该分支（含子组件实例），为假时卸载并移除 DOM——节点与实例随条件创建销毁，切换成本高（挂载/卸载、状态重建），但初始不渲染的内容零开销，且未渲染分支不占 DOM。v-show 编译为对元素 style.display 的绑定（保留元素，仅切换显示），始终渲染并保留 DOM 与组件状态，切换只是样式操作，成本低；代价是"隐藏"内容仍占用 DOM 与初始渲染成本。编译产物：v-if 是分支化的 VNode 结构（配合块收集），v-show 是带动态 style 绑定的单节点。边界选择：初始无需展示且很少切换（权限区块、条件步骤）用 v-if；需要频繁切换（Tab 内容、下拉面板）且希望保留状态用 v-show；注意 v-show 不支持 与组件外的多根（需包裹），v-if 可与 v-else-if/v-else 成链。

本题考察两个条件指令的"渲染策略"差异：v-if 管生命周期（创建/销毁），v-show 管样式（显示/隐藏）。回答时对比编译产物、运行时成本与状态保留行为，并按"切换频率 × 初始需求"给出选择原则，即完整。

• lit-html：JS 标签模板 + 动态部分（表达式槽位）的增量更新
• Vue：模板编译为渲染函数 + VNode/块优化（或 Vapor 细粒度）
• 两者的响应式模型（Lit 手动/信号 vs Vue 自动依赖收集）

lit-html 用 JS 标签模板字面量（html...）定义模板：静态字符串部分解析一次缓存，表达式槽位（${expr}）在每次渲染时求值并做增量更新（按槽位比较、直接 patch DOM），更新粒度是"表达式级别"，无需虚拟 DOM 树；响应式由开发者结合 Lit 的 reactive properties 或信号库驱动（变更后调用 render 或自动调度）。Vue 模板经编译器处理（静态提升、PatchFlag、块收集；Vapor 模式更是直接生成细粒度 DOM 指令），响应式自动依赖收集——数据变化自动触发最小更新，无需手动调度。取舍：Lit 极轻、贴近 Web Components 标准、无框架约束，适合自定义元素、库与多框架嵌入场景，但模板能力（指令、条件/循环语法糖）与生态工具较原生；Vue 提供完整的响应式体系、组件模型与生态（路由、状态、SSR），适合应用级开发，模板编译优化对复杂页面收益更大。现代工程按"需要 Web Components 标准形态与轻量嵌入，还是需要框架级能力与生态"选择。

本题考察两种模板技术的范式差异：lit-html 是"运行时标签模板 + 槽位更新"，Vue 是"编译优化 + 响应式自动派发"。回答时从模板机制、响应式模型、生态定位三个维度对比，并落到工程选型依据，即为核心。

• 场景化基准设计：首屏、局部更新、滚动、长时间驻留
• 指标采集：retained heap、GC 暂停、FPS、INP、更新吞吐量
• 控制变量与统计方法（多轮取中位数、真实设备）

基准设计要点：构造十万行可编辑表格的同一业务实现（相同数据模型与交互），分别用 Vapor 与 VDOM 编译运行。场景分四组：首屏（冷启动到可交互时间、初始渲染耗时与峰值内存）、局部更新（高频单格编辑、批量更新、行增删排序的更新耗时与吞吐量——每秒完成更新次数）、滚动（长列表滚动流畅度，采集 FPS 与长任务统计）、长时间驻留（持续操作 10-30 分钟，观察 retained heap 增长曲线与 GC 暂停频率/时长，用 Performance 面板或 PerformanceObserver 的 longtask 与 GC 事件）。采集与统计：Chrome DevTools Performance/内存快照、Lighthouse CI 或自建 PerformanceObserver 脚本，多轮（10+ 次）运行取中位数/百分位，控制浏览器环境、数据量与操作脚本一致；INP 模拟真实交互延迟（点击/输入后的响应时间），FPS 用 rAF 计数。解读：不追求单一指标胜出，按场景权衡——局部高频更新看吞吐与 INP，长时间驻留看内存曲线与 GC，首屏看加载与渲染耗时，最终结合生态兼容与迁移成本做决策。

本题考察性能基准的方法论：回答须体现"场景划分 + 指标对应 + 统计严谨"的设计能力。四组场景各配适切指标（首屏→加载/峰值内存、更新→吞吐/INP、滚动→FPS、驻留→retained heap/GC），并强调控制变量与多轮统计，即达到工程深度。

• Vapor 不支持 Options API，遗留组件需以兼容形态接入
• 编译边界的放置：在边界组件处切换渲染后端
• 边界处的桥接（props/事件/插槽透传）

Vapor 的编译边界应放在"Vapor 能力边界"处：Vapor 父组件的模板中，把遗留 Options API 组件作为普通组件引用——运行时框架会在该组件处按"组件级渲染后端"分派，遗留组件内部仍走其既有的渲染与更新路径（VNode/组件实例机制），Vapor 组件树在该边界外工作。工程上需要确认：编译配置允许混合模式（Vapor 组件与普通组件共存），边界组件本身不含 Vapor 独占模板能力（如依赖 Vapor 编译优化的指令），并显式保证边界处的 props/emit/slot 透传语义一致。验证要点：组件实例身份稳定（KeepAlive 缓存下不重复挂载）、响应式订阅与更新双向正确（Vapor 侧状态变化驱动遗留组件更新，反之亦然）、生命周期顺序（挂载/卸载、activated/deactivated）符合预期、无重复 DOM 挂载与 retained heap 增长。若遗留组件依赖 VNode 级 API（手动操作 VNode），需在边界处隔离为独立子树（如用 component 包装或动态组件过渡层）。

本题考察 Vapor 混合架构的边界设计：核心是"编译边界 = 组件边界"，在边界组件处两个渲染后端共存并通过组件契约（props/事件/插槽）通信。回答时给出边界放置原则、桥接要点与验证清单，即构成工程化方案。

• VDOM 岛：在 Vapor 树中嵌入仍走 VDOM 渲染的子组件
• 边界组件的稳定身份与切换策略
• 焦点与动画状态的保持（不重建 DOM 节点）

当 Vapor 树中需要 Transition/TransitionGroup 或依赖 VNode 钩子的能力时，把该区域封装为"VDOM 岛"：用一个明确的边界组件（普通 VDOM 渲染路径的组件）包裹动画区域，Vapor 侧只负责在边界处传入 props 与切换条件，动画逻辑完全在 VDOM 岛内执行。关键是保持"节点身份稳定"：边界组件及岛内内容在条件切换时不应被卸载重建——Vapor 侧对边界组件的引用保持稳定（使用 v-if 包裹时确保条件分支整体切换而非重建组件定义）、配合 KeepAlive 或显式 key 策略保证同一实例复用，从而 DOM 节点身份、输入焦点与动画进行中的状态不被破坏；切换后动画状态（enter/leave 中间态）由岛内 Transition 接管，避免因 DOM 重建导致动画中断或从零开始。隔离范围应最小化（仅动画相关区域），岛内使用 VDOM 生态能力，岛外继续享受 Vapor 的细粒度更新；验证时关注切换过程中的焦点轨迹、动画完成回调与无重复挂载。

本题考察 Vapor 生态缺口下的工程降级：核心是"隔离边界 + 身份稳定"。回答时说明 VDOM 岛的封装方式、避免 DOM 重建的 key/KeepAlive 策略、以及动画状态接管机制，并强调最小化隔离范围与验证方法，即完整。

• 不兼容特征识别：VNode 检查、slot 克隆、运行时渲染 API 调用
• 依赖分析与编译范围配置（逐组件 opt-in）
• 适配层方案：包装组件、VDOM 岛、双轨构建

识别阶段：静态扫描业务对组件库的使用面，结合库文档与源码特征——检查是否使用 VNode（cloneVNode、createVNode、vnode 类型判断）、是否克隆 slot（renderSlot/slot 函数手动处理）、是否调用运行时渲染 API（h 返回 VNode 并操作）等；动态验证：在 Vapor 构建下运行冒烟用例，观察警告与行为异常（组件不渲染、更新失效、slot 内容错位）。适配层：不兼容组件保留 VDOM 渲染路径，通过"包装组件 + 编译范围配置"把它们钉在普通模式——Vapor 的 opt-in 机制按组件控制编译范围，业务页面只对自身组件启用 Vapor，第三方组件默认不进入 Vapor 编译；对需要深层嵌套的场景，用 VDOM 岛封装不兼容组件子树，岛内按 VDOM 契约工作。阻止进入编译范围：配置层面的 allowlist（明确启用 Vapor 的组件列表）+ deny/依赖规则（检测到不兼容库时告警或自动回退），CI 中加入兼容性检查。灰度：先小范围页面启用、观察功能回归与性能数据，逐步扩大；保持双轨产物与一键回滚。

本题考察 Vapor 迁移的兼容性工程：回答按"识别（静态+动态）→ 隔离（编译范围/VDOM 岛）→ 治理（规则与 CI）→ 灰度"四步展开。能提到 opt-in 机制与 allowlist 是治理关键、包装组件是适配手段，即构成完整方案。

• 组件级 opt-in 的配置与渐进启用
• 灰度指标：性能、错误率、功能回归的观测
• 产物双轨：Vapor 与 VDOM 两种构建共存

opt-in 设计：以组件为最小启用单位，构建配置声明启用 Vapor 的组件清单（allowlist），未声明组件保持 VDOM，团队可按模块/页面渐进启用，无需整树重写；支持嵌套混合（Vapor 组件内嵌 VDOM 子组件）让迁移路径平滑。灰度指标：功能维度（错误率、页面异常、交互回归的埋点）、性能维度（首屏耗时、更新吞吐、INP、内存曲线）、构建维度（产物大小、chunk 数量），按页面/流量比例灰度（如 5% → 50% → 100%），对照组同页面 VDOM 产物。产物双轨：构建流水线同时产出 Vapor 与 VDOM 两套产物（或运行时开关切换编译后端），同一代码库、同一部署通道，通过配置中心/环境变量切换生效版本，保证任一时刻可回退。一键回滚：配置开关即时切换回 VDOM 产物（灰度态）或发布通道回退（全量态），回滚不影响数据与用户状态；配合 CI 的兼容性检查（不兼容依赖检测）在入口阻断风险变更。全程保持"小步快跑、可观测、可撤销"。

本题考察大规模技术切换的工程治理：核心是"渐进启用（opt-in）+ 数据决策（灰度指标）+ 双轨保障（产物共存）+ 快速回退（开关）"。回答按四要素展开并说明它们如何协同（灰度数据驱动扩大范围，双轨保证随时回滚），即构成完整方案。

• 实例身份：KeepAlive 缓存与切换时实例复用的一致性
• 订阅清理：卸载/缓存挂起时响应式依赖与副作用释放
• DOM 所有权：Teleport 目标与组件树的归属判定

验证与保障分三层。实例身份：KeepAlive 下混合树切换时，同一组件应保持同一实例（activated/deactivated 交替而非挂载/卸载循环）——用钩子日志与实例引用对比验证；异步组件切换时确认加载/错误/重试状态机正常、动态导入不重复请求。订阅清理：切换与缓存挂起时，watch/effect/computed 随组件作用域正确停止（onScopeStop、onUnmounted、onWatcherCleanup 生效），事件监听与外部订阅释放——用内存快照对比"切换前/中/后"的订阅者计数与事件监听器泄漏检测（DevTools 的 Performance monitor、chrome://memory 或自建 WeakRef 探测）。DOM 所有权：Teleport 内容挂到目标容器后，归属与释放必须一致——卸载时目标容器内节点完整移除（无残留）、重复切换不产生重复副本；用 DOM 节点计数与 MutationObserver 验证。内存验证：长时间反复切换后采集 retained heap 与堆快照 diff，确认无持续增长（稳定曲线而非线性增长），结合 GC 前后对比排除假象；发现异常时用 allocation instrumentation 定位持有链。

本题考察混合渲染架构下的生命周期与内存治理：回答按"身份（实例复用）→ 清理（订阅释放）→ 所有权（DOM 归属）→ 验证（快照与曲线）"组织，每层给出具体验证手段，即构成可落地的排查清单。