Vue3 on ZiYang FrontEnd Interview

Vue3与Vue2响应式原理差异

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度：框架机制理解、响应式原理深度、API设计思想
技术评估点：

对象属性检测的全面性（新增/删除属性）
数组监听机制差异
响应式初始化性能特征
数据结构支持范围扩展
依赖收集与触发效率优化

技术解析

关键知识点

Proxy拦截能力 > Object.defineProperty局限性 > 数组方法重写机制

原理剖析

检测能力：
Vue2通过Object.defineProperty劫持已有属性，新增/删除属性需Vue.set/Vue.delete。Vue3的Proxy代理整个对象，通过get/set/deleteProperty拦截器自动捕获所有属性变动。
数组处理：
Vue2重写数组原型方法（push/pop等）并手动触发更新，但无法检测索引赋值（arr[2]=x）和length修改。Vue3的Proxy可直接捕获数组索引赋值、方法调用及长度变化。
性能优化：
Vue2在初始化时递归遍历所有属性设置getter/setter，深层对象性能损耗大。Vue3的Proxy采用惰性劫持，仅在访问时创建响应式关联，减少初始化开销。

常见误区

误以为Proxy一定更快（大规模属性访问场景Proxy开销可能更大）
忽略Vue3仍需ref处理基础类型（Proxy无法代理原始值）
混淆数组响应式实现方式（Vue3仍需要特殊处理部分数组操作）

问题解答

Vue3的Proxy方案相比Vue2有以下关键改进：

属性检测：Proxy原生支持属性增删检测，无需特殊API，解决Vue2的动态属性追踪痛点。
数组处理：直接响应索引赋值和length变化，无需重写数组方法，代码更简洁。
性能优势：惰性劫持减少初始化消耗，嵌套对象性能提升约50%（Vue官方数据）。
数据结构：支持Map/Set等ES6集合类型，扩展响应式系统适用范围。

改进意义在于提升开发体验（减少手动干预）、降低内存占用（统一依赖存储）、提高框架性能基准。

解决方案

 // Vue2数组处理示例 
const vm = new Vue({ 
 data: { 
 list: [1,2,3] 
 }, 
 methods: { 
 update() { 
 this.list[1]5 = 5; // 不触发更新 
 this.$set(this.list, 1, 5); // 必须使用API 
 } 
 } 
}); 

// Vue3等效实现 
const state = reactive({ list: [1,2,3] }); 
state.list[1] = 5; // 自动触发响应

可扩展性建议：

Proxy替代Object.defineProperty的原因

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该题主要考查候选人以下核心能力：

响应式原理理解：对比新旧响应式方案的实现差异
ES6新特性掌握：Proxy和Reflect API的实际应用
框架演进洞察力：理解架构升级背后的工程考量

具体技术评估点包括：

Object.defineProperty在数组监听和动态属性上的局限性
Proxy在深层对象代理中的按需响应机制
属性删除、数组索引修改等边缘场景的处理差异
响应式系统性能优化的实现原理

技术解析

关键知识点

Proxy > Object.defineProperty > 数组方法重写 > 响应式初始化性能

原理剖析

Object.defineProperty通过劫持对象属性的getter/setter实现响应式，但存在三个致命缺陷：

数组监听缺陷：只能通过重写数组原型方法拦截变更，无法检测索引赋值（arr[2]=1）和length变化
属性新增无效：初始化后添加的属性无法自动响应，必须使用Vue.set
性能瓶颈：递归转换整个对象所有属性，造成初始化性能损耗

Proxy通过创建对象代理层，使用Reflect实现操作转发，优势显著：

 const proxy = new Proxy(obj, {
 get(target, key) {
 track(target, key) // 依赖收集
 // 嵌套对象延迟代理（提升性能关键）
 return isObject(res) ? reactive(res) : res 
 },
 set(target, key, value) {
 trigger(target, key) // 触发更新
 return Reflect.set(...arguments)
 }
})

常见误区

误认为Proxy可以直接代理嵌套对象（实际需要递归代理）
混淆数组方法重写与Proxy原生拦截的区别
忽视Reflect在保持代理行为一致性中的作用

问题解答

Vue3选用Proxy主要因其解决了三大核心问题：

reactive与ref的核心区别

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度：Vue响应式原理深度理解、API设计差异辨析、数据类型处理能力
技术评估点：
1. Proxy与getter/setter实现机制差异
2. 基本类型与引用类型响应式处理限制
3. 自动解包特性与.value访问的必要性
4. 引用稳定性与响应式保持能力
5. 对象类型在两种API间的转换关系

技术解析

关键知识点

Proxy响应式代理 > getter/setter拦截 > 自动解包机制 > 引用类型包装原理

原理剖析

reactive() 使用Proxy代理整个对象，递归转换嵌套属性。直接操作属性触发响应，适用于引用类型数据。ref() 通过对象包装和value属性访问，利用getter/setter实现拦截，支持任意数据类型。当值为对象时，内部自动调用reactive转换。

常见误区：

认为ref不能处理对象类型（实际上会自动调用reactive）
在模板中错误使用.value（模板自动解包）
在reactive对象中手动解包嵌套的ref

问题解答

根本差异：reactive基于Proxy代理对象实现响应式，ref通过对象包装的value属性存取触发响应。ref.value的设计使基本类型可通过引用传递，而Proxy无法直接代理非对象值。

必须使用ref的场景：

处理字符串/数值等基本类型时（无法被Proxy代理）
需要保持引用稳定性时（如需要替换整个值并保持响应）

转换示例：

 // ref对象转reactive
const countRef = ref(0)
// 自动解包：访问state.count无需.value
const state = reactive({ count: countRef })
console.log(state.count) // 0

// reactive对象转ref
const data = reactive({ a: 1 })
const dataRef = ref(data) // 等价于ref(reactive({a:1}))
console.log(dataRef.value.a) // 1

深度追问

为什么模板中访问ref不用.value？
模板编译时自动解包，仅顶层ref属性需要.value

reactive处理基本类型的限制

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该题主要考察以下核心维度：

响应式系统原理：理解Proxy在Vue3中的核心作用及局限性
数据类型认知：基本类型与引用类型在内存管理的本质差异
API设计思想：框架为何通过不同API(reactive/)处理不同数据类型
框架限制规避：掌握响应式失效场景的解决方案

具体评估点：

Proxy代理机制对数据类型的限制
基本类型的不可变性（Primitive Immutability）问题
reactive与ref的底层实现差异
响应式依赖收集的实现路径
框架的防御性编程策略

技术解析

关键知识点

Proxy代理机制 > 基本类型存储方式 > 响应式依赖收集

原理剖析

Vue3的响应式系统基于Proxy实现对象属性访问拦截。基本类型（String/Number等）存储在栈内存中，具有不可变性（重新赋值即创建新值）。Proxy只能代理对象，通过对属性get/set操作的拦截建立依赖跟踪。当使用reactive(42)时：

Proxy无法作用于非对象类型，导致响应式链路断裂
框架内部会抛出"value cannot be made reactive"警告
实际返回的仍是原始数值，失去响应能力

常见误区

误以为reactive会自动包装基本类型
混淆ref与reactive的适用场景
不理解Proxy只能代理对象引用
试图通过对象包装解决但未正确处理（如reactive({val:5}）的嵌套问题

问题解答

Vue3的reactive()强制要求对象参数的核心原因在于其依赖Proxy实现属性访问拦截。基本类型在内存中以值形式存在，Proxy无法直接代理原始值。当尝试reactive(5)时：

Proxy代理失败，无法建立属性访问监听
数值变更时无法触发Setter逻辑
框架在开发模式下会发出类型警告

解决方案是使用ref()，其通过将基本类型包裹在{ value: xxx }对象中，使Proxy可以代理该包装对象。访问时通过.value属性实现依赖追踪，数值变更时触发响应更新。

解决方案

 // 错误用法：直接代理基本类型
const invalid = reactive(0) // 返回原始值，失去响应性

// 正确方案：使用ref包装
const count = ref(0)
// DOM模板中自动解包
{{ count }}

// 逻辑层通过.value操作
function increment() {
 count.value++
}

优化建议：

watch与watchEffect的差异

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该问题主要考察以下核心维度：

响应式系统理解：对Vue3响应式原理及Watcher工作机制的掌握
API设计差异：区分两种观察器在底层实现上的关键差异
性能优化意识：根据不同场景选择最佳监听方案的决策能力

具体技术评估点：

依赖收集机制（显式指定 vs 自动追踪）
执行时机控制（立即执行与延迟执行）
回调参数的设计差异
副作用清理与执行顺序控制
多状态关联时的触发策略优化

技术解析

关键知识点

依赖收集：watch显式指定依赖 vs watchEffect自动收集
执行策略：watchEffect立即执行 vs watch的lazy初始化
参数特征：watch获取新旧值 vs watchEffect无值参数

原理剖析

watchEffect基于Vue的响应式跟踪系统，在同步执行回调时建立依赖关系图。当任何响应式依赖变更时，触发副作用重新执行。其采用getter拦截实现自动依赖收集，类似计算属性的工作机制。

watch需要显式声明监听目标，底层通过遍历监听源构建依赖关系。其回调接收新旧值对比，内部使用值快照机制保证数据一致性。

 // watch实现伪代码
function watch(source, cb) {
 const getter = isRef(source) 
 ? () => source.value
 : () => traverse(source)
 
 let oldValue
 const job = () => {
 const newValue = effect.run()
 cb(newValue, oldValue)
 oldValue = newValue
 }
}

// watchEffect实现
function watchEffect(effect) {
 const reactiveEffect = new ReactiveEffect(effect)
 reactiveEffect.run()
}

常见误区

误认为watchEffect无法获取旧值（正确方式：需手动维护状态）
在watch回调中修改监听源导致无限循环（需添加执行条件判断）
忽略flush timing配置对DOM更新的影响（post vs sync）

问题解答

watch与watchEffect的核心差异体现在：

Options API与Composition API架构对比

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下核心能力维度：

框架机制理解：对比两种API设计范式的实现原理与设计哲学
工程化思维：评估代码组织方式对复杂系统维护的影响
逻辑抽象能力：判断对逻辑复用模式的理解深度

具体技术评估点：

Options API的碎片化问题（数据/方法/生命周期分散）
Composition API的函数式编程优势
基于功能组织的代码封装策略
响应式系统在两种模式下的实现差异
逻辑复用的实现路径差异（Mixins vs Composition函数）

技术解析

关键知识点

Composition API > 逻辑聚合 > 响应式API > 代码可维护性 > TypeScript支持

原理剖析

Options API通过对象选项（data/computed/methods）组织代码，导致同一功能逻辑分散在不同选项块中。例如用户验证功能可能涉及：

data中的表单字段
methods中的提交方法
watch中的字段校验
mounted中的初始加载

Composition API通过setup()函数实现：

使用ref/reactive集中声明响应式数据
将相关逻辑封装为独立函数（如useFormValidation）
通过return暴露必要属性和方法

这种基于功能组织的模式类似乐高积木，开发者可以自由组合逻辑模块。同时由于函数闭包特性，组合函数内可直接使用相关响应式API，解决了Options API中必须通过this访问实例属性的限制。

常见误区

认为Composition API只是语法糖（实际改变了代码组织范式）
在setup中过度使用逻辑混合（应保持单一职责）
忽视生命周期钩子的使用差异（onMounted代替mounted）

问题解答

Options API与Composition API的核心差异在于代码组织范式：

横向切割 vs 纵向聚合：Options API按功能类型切割代码（数据归data，方法归methods），Composition API按业务功能聚合代码
逻辑复用方式：Options API依赖mixins（存在命名冲突风险），Composition API通过可组合函数实现精准复用
类型推导：Composition API的函数式结构更利于TypeScript类型推导

示例：用户定位功能在Options API中的实现：

 // 分散在多个选项块
export default {
 data() {
 return { coords: null }
 },
 mounted() {
 navigator.geolocation.watchPosition(
 pos => this.coords = pos
 )
 },
 methods: {
 formatCoords() { /* 格式化逻辑 */ }
 }
}

使用Composition API重构：

组合式API常用方法解析

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考核以下核心能力维度：

响应式系统原理：对Vue3响应式机制的理解深度
组合式API应用能力：核心API的适用场景与实现差异
异步状态管理：事件循环与响应式更新的协同机制

具体技术评估点：

ref与reactive的响应式实现差异
computed的缓存特性与依赖收集机制
provide/inject的跨层级通信原理
微任务队列与DOM更新时机的关联性

技术解析

关键知识点

响应式基础（ref/reactive） > 计算属性（computed） > 依赖注入（provide/inject） > 异步更新机制

原理剖析

ref：通过Object.defineProperty实现基本类型值的响应式包装，内部值存储在.value属性中。当操作.value时触发依赖收集与更新通知。
reactive：基于Proxy代理对象，实现深层次响应式。直接操作属性即可触发更新，但解构会丢失响应性。
computed：惰性求值的响应式引用，依赖变更时缓存失效。内部通过effect实现依赖追踪。
异步陷阱：Vue的响应式更新在同步代码中自动批处理，但在异步回调（如setTimeout或Promise）中直接赋值.value可能导致更新未及时触发，需配合nextTick确保DOM更新队列执行。

常见误区

误将reactive用于基本类型导致性能浪费
异步回调中遗漏.value操作引发更新丢失
混淆computed与methods的使用场景

问题解答

核心API作用：

ref：包装基本类型值为响应式对象，通过.value访问
reactive：创建深层次响应式对象，适用于复杂数据结构
computed：创建依赖其他响应式状态的计算属性，具有缓存优化
provide/inject：实现跨组件层级的状态注入，解决prop逐层传递问题

异步场景注意点：在异步回调中直接修改.value可能错过Vue的批量更新时机。由于Vue的响应式更新在同步任务中合并处理，而异步任务处于新的调用栈（Call Stack），此时赋值操作会立即触发渲染队列，可能导致重复计算或视图更新不同步。需在修改后调用nextTick确保更新时序正确。

解决方案

编码示例

 // 异步请求中的正确用法
const dataRef = ref(null);

fetchData().then((response) => {
 dataRef.value = response; // 正确触发响应式更新
}).catch(() => {
 dataRef.value = null; // 边界条件处理
});

// 组件卸载时取消请求（示例）
onBeforeUnmount(() => {
 abortController.abort();
});

优化建议

低端设备优化：对大型响应式对象使用shallowRef减少代理开销
高并发场景：结合watchEffect自动清理副作用，避免内存泄漏

深度追问

reactive处理Map/Set的局限？ 回答提示：需使用reactive包装容器+自定义拦截器

script setup语法糖的优势

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该题目主要考察以下核心能力维度：

Vue编译原理理解：能否解释<script setup>如何通过编译器转换生成标准组件代码
Composition API运用能力：评估对新型组件编写模式的理解深度
工程化效率认知：分析语法糖特性对开发体验的改善作用

具体技术评估点：

编译器对顶层绑定的自动暴露机制
编译器宏（如defineProps）的工作原理
相比传统Options API的代码精简效果
类型推导与TS支持的实现方式
运行时性能与编译器优化的关系

技术解析

关键知识点

编译器转换 > 自动暴露机制 > 编译器宏支持 > 类型推导优化

原理剖析

编译时转换：<script setup>在编译阶段会被转换为标准<script>组件格式。例如：
```
 // 源码
<script setup>
const count = ref(0)
</script>

// 编译后
export default {
 setup() {
 const count = ref(0)
 return { count } // 自动收集顶层变量
 }
}
 
```
编译器通过AST分析识别顶层变量，自动生成return语句暴露变量。
自动暴露机制：
- 仅暴露顶层声明的变量/函数
- 非顶层变量（如setup函数内部声明的变量）不会被暴露
- 通过expose编译器选项可精确控制暴露内容

编译器宏：

 // 源码
defineProps({ msg: String }) 

// 编译后
export default {
 props: { msg: String },
 // 自动注入setup函数
}

宏在编译阶段被解析为组件选项，实现类型安全的props/emits声明。

组合式API生命周期变化

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下维度：

Vue版本差异理解：对Options API与Composition API设计差异的掌握程度
生命周期机制：不同版本生命周期钩子的触发时机与使用场景
组合式API原理：setup函数执行时机及其对传统生命周期的替代方案

具体评估点：

组合式API钩子命名规范的设计意图
setup函数与beforeCreate/created的执行顺序关系
传统选项式生命周期在组合式模式下的迁移策略
组合式API中重复注册生命周期回调的能力
响应式系统初始化的阶段差异

技术解析

关键知识点

命名规则：onXxx函数式注册 > 选项声明式
执行时机：setup函数介于beforeCreate和created之间
替代方案：setup函数直接执行代码替代created逻辑

原理剖析

组合式API通过onMounted等函数注册生命周期回调，其命名采用动词+生命周期的结构（如onMounted），强调主动订阅行为。这种设计：

与watch等API保持命名一致性
支持多次调用注册多个回调
需显式导入避免全局污染

setup()执行阶段替代了传统选项中的beforeCreate和created：

 组件初始化
    ↓ 
beforeCreate
    ↓ 
setup() 执行
    ↓ 
created

在setup中：

同步代码相当于created阶段执行
无法访问beforeCreate阶段的组件实例（此时未初始化）

常见误区

错误尝试在setup中调用onCreated（不存在该API）
误认为setup完全替代所有生命周期（仍需通过钩子函数处理挂载后逻辑）
在setup外混合使用选项式生命周期导致执行顺序混乱

问题解答

组合式API将生命周期钩子改为on+大写事件名的函数形式（如onMounted），这种命名模式：

符合函数式编程范式，通过导入函数主动注册回调
支持同一生命周期注册多个处理函数
与watch(onInvalidate)等API命名风格统一

对于beforeCreate和created：

其功能被setup()函数替代
setup()内的同步代码在beforeCreate之后、created之前执行
原本在created中的初始化逻辑可直接写入setup顶层作用域
需要beforeCreate的场景可使用选项API混合写法（不推荐）

解决方案

代码示例

 import { onMounted } from 'vue'

export default {
 setup() {
 // 替代created的初始化逻辑
 const data = ref(null)
 
 // 替代mounted逻辑
 onMounted(async () => {
 data.value = await fetchData()
 })

 // 错误示例：试图访问未初始化的DOM
 // document.querySelector(...) 

 return { data }
 },
 // 必要时的传统钩子混合使用
 beforeCreate() {
 // 极少数需要早于setup执行的逻辑
 }
}

可扩展性建议

复杂逻辑使用setup函数拆分到独立hooks
异步初始化使用Suspense组件处理加载状态
性能敏感场景使用onDeactivated清理资源

深度追问

为什么没有onBeforeCreate？
→ 因组件实例在setup执行前未完成初始化，无法安全操作

组合式API逻辑复用实现

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考核以下核心能力维度：

组合式API机制理解：考察对Vue3组合式API设计理念的掌握，包括逻辑拆分与复用策略
响应式系统运用：检验ref/reactive等响应式API的正确使用，及在组合函数中的值传递
生命周期整合：评估在自定义hook中正确绑定/清除副作用（如事件监听、异步请求）
代码抽象能力：验证业务逻辑解耦能力，包括参数处理、状态暴露、错误边界等工程化实践

具体技术评估点：

组合函数的命名规范与结构
响应式数据在组件间的状态保持
生命周期钩子的正确绑定
异步操作的竞态处理（如请求取消）
TypeScript类型支持实现

技术解析

关键知识点

Composition API Design > 响应式系统 > 生命周期管理 > TypeScript类型推导

原理剖析

组合函数本质是返回响应式状态+函数的闭包封装，利用Vue的setup()执行上下文实现逻辑复用。通过ref维持响应式引用，在onMounted等钩子中绑定原生事件或异步操作，通过onUnmounted进行资源清理，避免内存泄漏。

典型错误包括：

直接返回解构对象导致响应式丢失
未在卸载阶段移除事件监听
异步回调中使用过期状态

常见误区

在组合函数内直接修改DOM（违反响应式原则）
忘记处理异步操作的错误状态
多个组件实例共享同一响应式引用（未使用函数式返回）

问题解答

通过组合函数封装逻辑需遵循以下步骤：

创建以use开头的函数，使用ref/reactive封装状态
在setup阶段执行副作用（如事件绑定）
返回组件可用的响应式状态与方法
使用toRefs保持解构后响应式

鼠标跟踪器示例：

 import { ref, onMounted, onUnmounted } from 'vue'

export function useMouse() {
 const x = ref(0)
 const y = ref(0)
 
 const update = (e) => {
 x.value = e.pageX
 y.value = e.pageY
 }

 onMounted(() => {
 window.addEventListener('mousemove', update)
 })

 onUnmounted(() => {
 window.removeEventListener('mousemove', update)
 })

 return { x, y }
}

API请求示例：

Vue3的Tree shaking实现原理

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度：框架设计原理、模块化工程能力、构建工具理解
技术评估点：
1. ES模块静态分析机制与Tree shaking的关联性
2. Vue3编译器标记如何配合模块系统实现按需引入
3. 全局API设计对代码优化的负面影响
4. 框架架构演进对打包优化的影响
5. 功能模块解耦与代码可摇树性的关系

技术解析

关键知识点

ES Module静态结构 > 编译器模板分析 > 全局API副作用 > 模块解耦设计

原理剖析

Vue3通过以下技术栈实现Tree shaking：

模块化架构：将框架拆分为@vue/runtime-core等独立ES模块，每个功能（如keep-alive、transition）作为独立导出
模板编译器：在SFC编译阶段分析模板中实际使用的组件/指令，自动生成精准的import语句
函数式API设计：组合式API（ref、computed）均为命名导出，配合构建工具的dead code elimination

 // Vue3组件编译结果示例
import { createVNode, keepAlive } from 'vue'

// 仅当模板包含<keep-alive>时才会引入对应模块
export function render() {
 return createVNode(keepAlive, {/* props */})
}

常见误区

错误认为选项式API也能实现Tree shaking（实际上选项对象无法静态分析）
混淆编译时优化与运行时开销的关系
忽视sideEffects配置在打包流程中的作用

问题解答

Vue3通过三阶段实现Tree shaking：首先采用ES模块架构，所有功能模块独立导出；其次编译器在模板解析阶段标记实际使用的组件，生成精确的import；最后配合API的函数式设计消除副作用。以keep-alive为例，未使用时其模块不会被import，最终被Rollup等工具移除。相较而言，Vue2的全局API（如Vue.component）因挂载在单一对象上，导致构建工具无法判断使用情况，必须全量包含。

解决方案

架构对比

 // Vue2全局API（无法tree-shaking）
Vue.component('keep-alive', { /* 实现 */ })

// Vue3模块化设计（可摇树）
// 用户代码
import { KeepAlive } from 'vue'

// 构建后未使用模块被移除

编译器优化

模板编译阶段通过AST分析：

Fragment特性的多根节点支持

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度：Vue框架原理理解、虚拟DOM机制、版本差异分析能力
技术评估点：
1. Fragment节点在虚拟DOM中的表现形式
2. Vue3的patch算法对多根节点的处理逻辑
3. 编译器对多根模板的转换机制
4. 无容器元素对CSS布局的影响
5. 与传统Vue2单根限制的对比优势

技术解析

关键知识点

虚拟DOM结构 > Patch算法优化 > CSS层叠上下文

原理剖析

Vue3通过引入Fragment节点类型突破单根限制。当模板存在多个根节点时：

编译阶段将根层级元素转换为Fragment虚拟节点（vnode.type为Symbol类型）
渲染阶段处理Fragment时，仅将其子节点挂载到父级，自身不生成真实DOM
Patch过程：
- 对比新旧Fragment时，执行patchChildren而非patch
- 通过key值复用DOM元素，动态调整子节点顺序
- 使用最长递增子序列算法优化移动操作

类比快递分拣：Fragment类似透明包装袋，仅用于归类物品（子节点）但不增加额外重量（DOM层级）

常见误区

误认为多个根节点会创建多个组件实例
混淆Fragment与空div的DOM渲染差异
未考虑动态组件可能导致的位置索引错乱

问题解答

Vue3通过Fragment虚拟节点实现多根模板支持。在编译阶段将多根模板转换为带有Symbol类型标识的Fragment虚拟节点，该节点在patch过程中仅作为逻辑容器，通过对比子节点列表完成DOM更新。相较于Vue2强制包裹的div，Fragment避免了不必要的DOM层级，解决如flex/grid布局中因冗余嵌套导致的样式错乱问题。

具体处理时，当检测到新旧vnode均为Fragment类型，直接进入子节点diff流程。通过双端对比算法优化更新效率，仅对发生变化的子节点进行DOM操作。这种机制确保在保留响应式特性的同时，维持与CSS布局系统的原生兼容性。

解决方案

 // Vue3编译后的渲染函数示例
import { createVNode, openBlock, createBlock } from 'vue'

export function render() {
 return (
 openBlock(),
 createBlock(
 Fragment, 
 null,
 [
 createVNode('div', null, 'Node1'),
 createVNode('span', null, 'Node2')
 ],
 PatchFlags.STABLE_FRAGMENT // 标记子节点结构稳定
 )
 )
}

边界处理：

Teleport组件的DOM传送场景

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度：

Vue框架特性理解（Teleport组件机制）
CSS层叠上下文原理
DOM渲染层级控制实战经验

技术评估点：

Teleport组件如何解决样式隔离问题
堆叠上下文（Stacking Context）的形成与影响
CSS选择器在动态DOM环境中的可靠性
多层级组件间的z-index管理策略
响应式系统与DOM操作执行的时序问题

技术解析

关键知识点

堆叠上下文规则 > Teleport渲染机制 > CSS选择器穿透性
z-index生效条件：元素须处于同一堆叠上下文才可比较层级
目标容器稳定性：确保CSS选择器定位的DOM节点存在且稳定

原理剖析

当使用<Teleport to="body">传送模态框时，组件将被渲染到<body>末尾，脱离原组件树的渲染上下文。此时模态框的z-index直接与<body>子节点比较，避免被父组件的低层级上下文覆盖。浏览器渲染时，后出现的DOM节点默认层级更高，但需确保模态框的z-index值足够大（推荐2000+）以覆盖页面其他元素。

常见误区：

错误认为提高z-index即可解决所有层级问题，忽视堆叠上下文隔离
使用非稳定选择器（如.class）可能导致目标容器意外变更
未处理SSR场景下客户端注水时的DOM一致性

问题解答

避免z-index问题：

将模态框传送至<body>末尾，脱离父级堆叠上下文
设置模态框z-index为2000以上（超越常规元素）
确保目标容器（如<body>）未创建新的堆叠上下文（避免使用transform/opacity）

to属性注意事项：

选择器应指向稳定存在的DOM节点（推荐ID选择器）
避免使用动态类名或复杂选择器，防止匹配元素变更
服务端渲染时需确保客户端注水后目标节点存在

解决方案

 // 安全使用Teleport的示例
<template>
 <Teleport to="#modal-root">
 <div class="modal" :style="{ zIndex: 2001 }">
 <!-- 模态内容 -->
 </div>
 </Teleport>
</template>

// 在public/index.html提前放置锚点
<body>
 <div id="app"></div>
 <div id="modal-root"></div> <!-- 专用容器 -->
</body>

优化建议：

Suspense组件的异步解决方案

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下核心能力维度：

React异步渲染机制：理解Suspense与React异步组件协同工作原理
组件状态协调：掌握fallback插槽在加载状态管理中的核心作用
错误边界设计：运用onErrorCaptured实现组件树异常捕获与降级处理
用户体验优化：实现加载骨架屏与优雅的错误提示方案

技术评估点：

Suspense与React.lazy的协同机制
错误边界组件与Suspense的嵌套顺序
异步加载过程中错误冒泡机制
骨架屏与错误回退的优先级逻辑

技术解析

关键知识点

Suspense工作流 > 错误边界机制 > React.lazy实现原理
错误冒泡捕获顺序 > 异步组件加载状态管理

原理剖析

Suspense通过子组件throw promise的机制实现加载状态协调。当包裹的异步组件处于加载状态时，React会暂停渲染并展示fallback内容。其核心流程为：

React.lazy创建的组件初始化时抛出Promise
Suspense边界捕获该Promise，触发加载状态
Promise完成后重新渲染
若加载失败，错误会冒泡至最近的错误边界

错误边界组件通过class组件+getDerivedStateFromError实现异常捕获。当与Suspense配合时，错误边界必须包裹Suspense组件，才能捕获异步加载过程中发生的错误。

常见误区

混淆Suspense与错误边界的职责（加载态与错误态）
错误边界未正确包裹Suspense导致异常逃逸
未处理异步组件加载失败场景

问题解答

Suspense通过双缓冲机制协调异步加载状态：当子组件未就绪时，触发fallback插槽内容渲染。结合错误边界时，需用错误边界组件包裹Suspense以捕获异步加载错误，形成完整的状态处理链。

典型实现方案：

错误边界组件使用componentDidCatch捕获异常
React.lazy动态加载目标组件
Suspense设置fallback骨架屏
错误边界包裹Suspense形成保护层

加载流程优先级：正常内容 > fallback > 错误提示。错误边界仅处理异常状态，不干扰常规加载流程。

解决方案

 // 错误边界容器
class ErrorBoundary extends React.Component {
 state = { hasError: false }
 
 static getDerivedStateFromError() {
 return { hasError: true }
 }

 componentDidCatch(error, info) {
 // 上报错误日志
 logError(error, info)
 }

 render() {
 return this.state.hasError 
 ? <ErrorView />
 : this.props.children
 }
}

// 异步组件加载
const LazyComponent = React.lazy(() => import('./Component'))

// 视图层组合
function App() {
 return (
 <ErrorBoundary>
 <Suspense fallback={<Skeleton />}>
 <LazyComponent />
 </Suspense>
 </ErrorBoundary>
 )
}

优化建议：

静态提升(Static Hoisting)优化原理

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该题目主要考察以下核心维度：

编译器优化原理：理解Vue3编译阶段的静态分析机制
虚拟DOM机制：掌握diff算法优化与静态节点标记的关联
运行时性能优化：评估hoisting技术对渲染性能的实际影响

具体技术评估点：

静态节点识别标准（没有动态绑定/ifeach/for）
提升后的虚拟节点缓存方式（常量声明位置与复用逻辑）
虚拟DOM diff过程中静态节点的跳过机制
编译器输出对比分析能力
优化前后的性能指标差异量化能力

技术解析

关键知识点

静态分析（Static Analysis）
常量提升（Hoisting）
虚拟DOM复用（VNode Reuse）
Diff算法路径优化

原理剖析

Vue3编译器在模板编译阶段通过AST分析识别静态节点（不含动态绑定/v指令的节点）。通过patchFlag标记进行节点类型分类，将纯静态节点提升到渲染函数外部作为常量。编译后的渲染函数中，静态节点引用常量而非每次重新创建。

当更新发生时，虚拟DOM树中的静态节点保持引用不变。Diff算法通过isSameVNodeType检查时，由于新旧虚拟节点的引用地址相同，直接跳过比较。对于静态子树，该优化可使diff时间复杂度从O(n)降为O(动态节点数)。

 // 编译前
render() {
 return h('div', [
 h('span', 'static'),
 h('p', this.dynamic)
 ])
}

// 编译后
const _hoisted = h('span', 'static') // 静态提升
render() {
 return h('div', [
 _hoisted, // 引用常量
 h('p', this.dynamic)
 ])
}

常见误区

误认为静态提升只作用于根节点（实际作用于所有层级静态节点）
混淆模板静态性与数据响应式的关系
认为优化仅减少内存分配（实际同时优化diff和内存）

问题解答

Vue3编译器通过静态分析识别不含动态绑定的节点，将其提升为渲染函数外部的常量。首次渲染创建静态VNode后，后续更新直接复用该引用。虚拟DOM diff时，由于新旧VNode引用相同直接跳过比较，将时间复杂度从O(n)优化为仅处理动态节点。

Vue3组件通信方式的变化

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该问题主要考查候选人以下三个维度的理解：

框架演进思维：理解Vue3精简核心代码库、拥抱Tree-shaking的设计哲学
响应式原理冲突：识别事件总线模式与响应式系统在内存管理、依赖追踪方面的根本矛盾
工程化权衡能力：对比内置事件机制与第三方库在类型安全、维护成本、性能开销等方面的差异

具体技术评估点：

事件总线模式导致的隐式耦合问题
响应式系统与手动内存管理的冲突
Tree-shaking机制对框架设计的影响
第三方事件库在TS支持、调试能力方面的优势

技术解析

关键知识点

响应式系统 > 内存管理 > Tree-shaking > 类型安全

原理剖析

Vue3的事件接口移除本质是响应式范式与事件驱动范式的冲突：

隐式依赖：事件总线创建全局订阅关系，与组件树结构解耦，导致调试时难以追踪事件流向
内存泄漏：手动管理$off的强依赖与响应式自动回收机制冲突，易出现未及时注销的监听器
架构污染：基于Vue实例的事件系统会携带完整的响应式能力，而mitt等库采用纯事件逻辑（类似Node.js的EventEmitter）

 典型问题场景：
组件A --$emit--> EventBus --$on--> 组件B
│ │
└--- 卸载时忘记$off -----------> 内存泄漏

常见误区

误认为$on/$off移除是API简化
混淆事件总线与全局状态管理
忽视组合式API与事件模式的范式冲突

问题解答

Vue3移除事件总线接口主要基于三个设计考量：

响应式治理：事件总线模式绕过Vue的响应式依赖追踪，导致组件卸载后残留订阅，破坏自动垃圾回收机制。mitt采用WeakMap存储监听器，在订阅者销毁时可自动释放内存
类型安全：第三方库如mitt提供完整的TypeScript支持，而Vue2的事件系统缺乏类型推导，
```
 // mitt示例类型约束
type Events = { foo: string }
const emitter = mitt<Events>()
 
```
体积优化：移除$on/$off符合Tree-shaking设计哲学，允许构建工具剔除未使用代码。第三方事件库（1KB）相比Vue2事件系统（内嵌在核心库）显著减小体积

解决方案

编码示例

 // 现代事件总线实现
import mitt from 'mitt'

type AppEvents = {
 'search': string
 'login': UserInfo
}

export const emitter = mitt<AppEvents>()

// 组件内使用
onMounted(() => {
 emitter.on('search', handleSearch)
})

onBeforeUnmount(() => {
 emitter.off('search', handleSearch) // 显式注销
})

// 事件触发
emitter.emit('search', query)

可扩展性建议

大流量场景：采用节流模式包装事件处理器
低端设备：使用Map替代Object存储监听器以提升性能
调试模式：开发环境添加事件追踪中间件

深度追问

如何实现跨组件事件追踪？ 通过包装emit/监听函数添加debug信息

mitt库与EventBus的核心差异

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下核心能力维度：

框架机制理解：对比第三方库与框架内置方案的实现差异
类型系统应用：TypeScript高级类型在事件总线场景的实践
内存管理意识：事件监听场景下的资源释放策略
模块化设计：轻量化方案与框架强耦合实现的取舍

具体技术评估点：

类型推导机制（泛型约束 vs 松散类型）
事件监听器生命周期管理策略
单例模式与实例化开销对比
通配符事件支持与扩展性设计

技术解析

关键知识点

TypeScript支持 > 内存泄漏预防 > 无实例化设计 > 通配符事件

原理剖析

类型安全：Mitt通过泛型参数约束事件类型，如mitt<Events>允许定义严格类型的事件名与载荷格式，Vue2的EventBus基于Vue实例的$emit/$on使用字符串类型事件名，缺乏类型校验
内存管理：Vue2需手动在组件beforeDestroy阶段调用$off，Mitt虽仍需手动调用off，但通过on返回的解绑函数（() => void）可与现代框架的onUnmounted钩子天然配合
实例差异：Vue EventBus需new Vue()创建实例（约20KB内存开销），Mitt采用纯对象发布订阅模式（<1KB），无虚拟DOM等额外开销
扩展机制：Mitt支持*通配符监听所有事件，事件处理函数接收type参数，Vue原生未提供类似功能

常见误区

认为Mitt会自动处理事件解绑（仍需主动调用）
误用Vue的EventBus类型定义导致TS类型不安全
低估实例化带来的内存消耗差异

问题解答

Mitt相较于Vue2 EventBus主要改进包括：

类型支持：通过泛型约束事件类型，杜绝错误事件名和错误载荷类型
内存防护：配合组合式API的onUnmounted可便捷实现监听清理，而Vue2选项式API易遗漏$off
零实例：纯函数实现无需创建Vue实例，包体积减少97%且无响应式系统开销
通配符监听：on('*')可统一处理日志上报等跨事件逻辑，Vue需手动维护事件列表

解决方案

 // Mitt类型安全示例
type CustomEvents = {
 'search': { query: string },
 'submit': FormData
};

const emitter = mitt<CustomEvents>();

// 组件内使用
emitter.on('search', ({ query }) => {
 if (query.length < 2) {
 console.error('Query too short');
 return;
 }
 // 搜索逻辑
});

// 组件卸载时自动解绑
onUnmounted(() => {
 emitter.off('search');
});

// 通配符监听所有事件
emitter.on('*', (type, detail) => {
 analytics.send(type, detail);
});

优化建议：

Modal组件设计（组合API+Teleport）

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下核心能力维度：

组合式API应用能力：考察对Vue3组合式API的逻辑封装能力，能否将状态管理与逻辑复用有机结合
Portal机制理解：验证对Teleport特性的理解深度，能否正确实现跨DOM层级渲染
交互设计完整性：检测键盘事件与点击事件处理的完备性，包括事件委托与冒泡控制

技术评估点包括：

响应式状态管理（ref/reactive）
Teleport的DOM挂载机制
事件监听的生命周期管理
可复用组件的接口设计

技术解析

关键知识点

Composition API逻辑封装 > Teleport实现机制 > 事件委托处理
模态框状态通过ref驱动，封装为独立可复用模块
Teleport解决z-index层级战争问题，确保模态框脱离父级上下文
通过事件源判断实现精准的遮罩层点击检测
通过键盘事件监听实现ESC关闭，注意多实例竞争条件

原理剖析

组合式API通过setup()函数将状态逻辑打包为独立单元，使用provide/inject实现跨组件状态共享。Teleport组件通过to属性指定目标容器，解决模态框受父容器overflow:hidden样式限制的问题。

事件处理需注意：遮罩层点击事件需校验event.target是否为遮罩层本体，防止内容区域点击误触发。ESC监听需在组件挂载时注册全局事件，并在卸载时及时销毁，避免内存泄漏。

常见误区

直接使用事件冒泡处理遮罩层点击，导致内容区域误触发
忘记移除全局事件监听导致多实例干扰
未处理多个模态框同时存在时的ESC关闭优先级

问题解答

使用组合式API封装模态框状态逻辑的核心是创建响应式状态容器。通过useModal函数导出isOpen状态和操作方法，Teleport组件确保模态框渲染到body末端。遮罩层点击关闭通过校验事件目标实现，ESC关闭使用document.addEventListener注册全局监听。

关键技术实现：

使用ref创建响应式状态
Teleport指定to="body"实现跨DOM层级渲染
通过event.target === modalRef.value精准判断遮罩层点击
在onMounted生命周期注册/移除事件监听

解决方案

编码示例

 // 组合式逻辑封装
const useModal = () => {
 const isOpen = ref(false)
 
 const open = () => (isOpen.value = true)
 const close = () => (isOpen.value = false)

 return { isOpen, open, close }
}

// 模态框组件
<template>
 <teleport to="body">
 <div v-if="isOpen" class="modal-mask" @click="handleMaskClick">
 <div class="modal-content" ref="modalContent">
 <slot />
 <button @click="close">关闭</button>
 </div>
 </div>
 </teleport>
</template>

<script setup>
import { ref, onMounted, onBeforeUnmount } from 'vue'

const props = defineProps({
 // 支持自定义关闭策略
 closeOnEsc: { type: Boolean, default: true }
})

const { isOpen, close } = useModal()
const modalContent = ref(null)

const handleMaskClick = (event) => {
 // 精准点击检测
 if (event.target === modalContent.value.parentElement) {
 close()
 }
}

// ESC关闭逻辑
const handleKeydown = (e) => {
 if (e.key === 'Escape' && props.closeOnEsc) {
 close()
 }
}

onMounted(() => {
 document.addEventListener('keydown', handleKeydown)
})

onBeforeUnmount(() => {
 document.removeEventListener('keydown', handleKeydown)
})
</script>

可扩展性建议

性能优化：使用CSS transform代替top/left定位提升动画性能
多实例支持：通过事件优先级队列管理多个模态框的ESC关闭顺序
无障碍支持：添加role=“dialog"和aria-modal属性
低端设备适配：增加触摸事件支持，优化移动端点击体验

深度追问

如何防止模态框内容被父组件CSS样式干扰？ 提示：Teleport的DOM脱离+CSS作用域控制

自定义指令API的生命周期变化

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该题主要考察以下核心能力：

框架机制理解：对Vue2到Vue3自定义指令API升级的迁移逻辑的掌握，尤其是钩子函数命名和触发逻辑的变化
生命周期对齐逻辑：理解指令生命周期与组件生命周期的对应关系，以及Vue3统一API命名背后的设计意图
版本差异分析：对比Vue2和Vue3的钩子触发顺序及参数变化，体现对底层原理的深入认知

具体技术评估点：

新旧钩子映射关系（如bind→beforeMount，inserted→mounted）
合并后钩子的触发时机（如mounted合并了元素插入和绑定的场景）
参数结构调整（如binding.value标准化、移除vnode.context）

技术解析

关键知识点

Vue3指令生命周期设计 > 与组件生命周期对齐 > 参数规范化

原理剖析

Vue3为统一API设计，将指令生命周期与组件生命周期对齐。原先的bind（元素绑定但未插入DOM）对应beforeMount，inserted（元素插入DOM后）对应mounted。而update和componentUpdated被拆分为beforeUpdate（数据变化但DOM未更新）和updated（DOM更新后）。

inserted的功能被合并到mounted中，触发逻辑变为：当指令绑定元素完成DOM插入且父组件挂载后触发，仅执行一次。此举消除了Vue2中bind和inserted的割裂感，例如在绑定动态样式后插入DOM的场景不再需要分开处理。

参数变化

Vue2：el, binding, vnode, oldVnode
Vue3：el, binding, vnode, prevVNode
binding对象新增instance属性指向组件实例，value和oldValue标准化为固定字段，删除expression字符串的冗余解析。

问题解答

Vue3的自定义指令生命周期钩子重命名主要是为了与组件生命周期对齐，提升API一致性。

重命名逻辑：
- bind → beforeMount（元素attribute绑定后，插入DOM前）
- inserted → mounted（元素插入父组件且子组件挂载完成）
- update和componentUpdated合并为beforeUpdate和updated
inserted合并逻辑：

原inserted的DOM插入检测被整合到mounted，当指令绑定元素首次完成DOM插入时触发。若元素初始为v-if="false"后变为true，会再次触发mounted。
参数变化：
- binding.oldValue直接反映旧值，无需通过update钩子对比
- vnode和prevVNode分别代表当前与上一次的虚拟节点
- 移除vnode.context，改为通过binding.instance获取组件实例

解决方案

编码示例

 const customDirective = {
 beforeMount(el, binding) {
 // 替代Vue2的bind：初始化样式
 el.style.color = binding.value;
 },
 mounted(el, binding) {
 // 替代Vue2的inserted：DOM插入后记录日志
 console.log(`Inserted to ${binding.instance.$el.tagName}`);
 },
 updated(el, binding) {
 // 替代Vue2的componentUpdated：更新后对比值
 if (binding.value !== binding.oldValue) {
 el.style.color = binding.value;
 }
 }
}

可扩展性建议

性能敏感场景：在beforeUpdate中缓存binding.value减少DOM操作
SSR兼容：在mounted中添加客户端特有逻辑，通过if (process.client)隔离
低端设备：在unmounted中手动清理事件监听，防止内存泄漏

深度追问

为何Vue3移除vnode.context？
答：与组件实例解耦，通过binding.instance显式获取

v-if与v-for优先级变化(Vue3)

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下三个核心维度：

Vue框架机制理解：考察对Vue指令优先级变化及编译原理的掌握程度
性能优化意识：评估对无效渲染的认知及避免策略
工程实践能力：测试在复杂场景下的指令组合使用技巧

具体技术评估点：

Vue3指令优先级变更的底层逻辑
无效循环渲染的产生原因及优化原理
template标签在指令组合中的桥梁作用
计算属性在数据预处理的性能优势

技术解析

关键知识点

Vue指令优先级 > 编译阶段处理顺序 > 虚拟DOM优化

原理剖析

Vue3通过编译器将template转换为渲染函数时，采用新的优先级策略：

静态分析阶段检测到v-if会生成条件判断逻辑分支
v-for指令被转换为可迭代的_createElementVNode调用
当两者共存时，v-if的判断条件会包裹整个v-for循环，形成类似伪代码结构：
```
 if (condition) {
 return list.map(item => createElement(...))
}
 
```

这种结构改变使得当condition为false时直接跳过整个列表渲染，避免了Vue2时代需要先遍历所有元素再逐个进行条件判断的资源浪费。

常见误区

误认为优先级变化仅影响运行时顺序
在条件判断依赖循环变量时直接混用指令
忽略计算属性缓存机制对重复计算的优化作用

问题解答

在Vue3中，v-if优先级高于v-for的设计通过编译阶段的静态分析优化，使得当条件判断失败时直接跳过整个循环的渲染逻辑。这避免了Vue2中先循环后判断导致的无效节点创建，尤其在大数据量场景下显著提升性能。

正确使用方法：

模板隔离法：使用<template>标签分离作用域

 <template v-if="isShow">
 <div v-for="item in list" :key="item.id">
 {{ item.name }}
 </div>
</template>

数据预处理：通过计算属性过滤数据源

 <div 
 v-for="item in filteredList"
 :key="item.id"
>
 {{ item.name }}
</div>

<script>
computed: {
 filteredList() {
 return this.list.filter(item => item.visible)
 }
}
</script>

解决方案

编码示例

 <!-- 方案1：模板包裹 -->
<template v-if="user.isAdmin">
 <ul>
 <li 
 v-for="item in sensitiveItems"
 :key="item.id"
 >
 {{ item.content }}
 </li>
 </ul>
</template>

<!-- 方案2：计算属性优化 -->
<template>
 <div 
 v-for="msg in filteredMessages"
 :key="msg.id"
 class="message"
 >
 <span v-if="!msg.isDeleted">{{ msg.text }}</span>
 </div>
</template>

<script setup>
const filteredMessages = computed(() => 
 messages.value.filter(m => m.valid && !m.isDeleted)
)
</script>

可扩展性建议

大数据量场景建议配合v-memo减少Diff计算
低端设备可使用<TransitionGroup>实现渲染批处理
配合<Suspense>实现异步数据加载时的优雅降级

深度追问

v-for中key的作用及错误使用后果?

v-memo指令的缓存优化作用

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下核心能力维度：

Vue框架原理理解：对Vue3新特性及虚拟DOM更新机制的掌握程度
性能优化思维：针对大型列表场景的渲染优化策略选择能力
API应用能力：对v-memo指令参数配置和边界条件的把控

具体技术评估点包括：

虚拟DOM diff算法瓶颈认知
记忆化技术（memoization）在框架层的实现原理
依赖数组（dependency array）的深浅比较机制
动态模板与静态子树的条件更新策略
指令使用误区与性能反模式识别

技术解析

关键知识点

虚拟DOM复用 > 依赖数组比较 > Patch算法优化

原理剖析

v-memo通过缓存虚拟DOM子树及其快照依赖值，在组件更新时：

对比当前依赖数组与缓存快照
若依赖未变更，跳过整个子树的patch过程
直接复用已存在的虚拟DOM节点

技术实现要点：

 const cached = {
 deps: prevDeps,
 vnode: prevVNode
}
if (isSame(cached.deps, newDeps)) {
 return cached.vnode
}

常见误区

在动态内容上使用导致更新失效（如：误缓存包含v-for索引的表达式）
依赖数组包含引用类型时未注意深浅比较规则
过度使用导致内存泄漏（缓存大量DOM节点）

问题解答

v-memo通过缓存虚拟DOM子树及对应的依赖快照，在组件更新时若依赖值未变化，直接跳过该子树diff过程。例如在表格渲染时，对稳定行数据声明v-memo="[row.id, row.status]，当行ID和状态未改变时，即使父组件触发更新，该行也不会重新渲染。

解决方案

编码示例

 <template>
 <tr v-for="row in rows" :key="row.id" v-memo="[row.id, row.status]">
 <!-- 静态内容占比80%的列 -->
 <td>{{ row.id }}</td>
 <td>{{ row.name }}</td>
 <td>{{ formatDate(row.createTime) }}</td>
 
 <!-- 动态内容需要排除在memo之外 -->
 <td :class="{ warning: row.status === 'pending' }">
 {{ row.status }}
 </td>
 </tr>
</template>

优化说明

时间复杂度：将O(n)的diff计算降为O(1)（命中缓存时）
内存消耗：需缓存N个vnode，适用于长列表但更新不频繁的场景
防踩坑：避免缓存包含index或临时ID的表达式

扩展建议

低端设备可结合<Teleport>分块渲染
高频更新场景建议改用v-once彻底静态化
监控内存使用情况防止过度缓存

深度追问

如何验证v-memo是否生效？

使用Vue DevTools的"Timeline"面板观察组件更新频率

渲染函数h函数的导入变化

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该问题主要考察以下三个核心维度：

模块化设计理解：评估对ES Modules机制及显式依赖管理的认知
编译优化原理：检验Tree-shaking工作机制及其在前端工程化的应用
框架架构演进：理解Vue3设计哲学变化对生态扩展性的影响

具体技术评估点：

ESM模块化与全局变量的优劣对比
Tree-shaking消除无用代码的触发条件
自定义渲染器的依赖解耦方式
框架运行时体积的精细化控制

技术解析

关键知识点

ES Modules > Tree-shaking机制 > 渲染器抽象层设计

原理剖析

Vue3将h函数从全局注入改为显式导入，主要基于：

模块精准控制：ESM强制显式依赖声明，避免隐式全局变量导致的命名冲突和不可预测性。通过import { h } from 'vue'明确标识依赖关系，符合现代打包工具（Rollup、Webpack）的静态分析要求。
Tree-shaking优化：当h函数未使用时，打包工具通过import语句可准确判定代码使用情况，将未引用的渲染函数剔除。对比Vue2全局注入模式，即使未使用h函数也会保留在最终产物中。
渲染器可插拔：自定义渲染器开发时，可通过不同import路径引入特定版本的h函数。例如：

 // 自定义WebGL渲染器
import { createRenderer } from '@vue/runtime-core'
import { nodeOps } from '@vue/runtime-webgl'
const { h } = createRenderer(nodeOps)
// 与传统DOM渲染器解耦

常见误区

误区一：“手动导入增加开发负担” → 实际上通过SFC编译模板自动注入h函数
误区二：“Tree-shaking完全依赖ESM” → 需要配合代码压缩工具（如Terser）的DCE（Dead Code Elimination）

问题解答

Vue3要求手动导入h函数的核心考量是：

组合式API的TS类型推导改进

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度：TypeScript集成能力、Vue框架原理理解、类型系统设计思想

TS类型推导机制：考察对泛型推断、类型收窄的理解
响应式API设计差异：对比ref/reactive与Options API的类型声明方式
上下文类型追踪：setup函数中变量引用的类型流维护
开发体验优化：类型提示准确性对编码效率的影响
复合类型处理：处理嵌套对象、联合类型时的类型保障

技术解析

关键知识点

泛型参数自动推断（ref('str') => Ref<string>）
函数式API的上下文保留（vs Options API的配置对象分离）
类型推导与响应式代理的协作（reactive<T>与UnwrapNestedRefs）

原理剖析

组合式API通过函数返回值类型显式声明类型系统路径。当开发者调用ref('value')时：

TS编译器自动推导value参数为string类型
ref函数泛型参数T被推断为string
返回类型Ref<string>携带类型元信息

在Options API中，类型声明分散在data、methods等独立配置项中，类型系统需通过ThisType等机制重建上下文关联。而setup函数采用命令式编码，变量引用形成显式依赖链，TS可通过代码顺序准确推导箭头函数返回值类型。

类型扩展：当使用reactive({ user: { name: '' } })时，TS会递归推导嵌套属性类型，而Options API的data需要手动声明接口或使用类型断言。

常见误区

混淆ref.value的类型（误判为包含value属性的普通对象）
Options API中未使用Type声明导致方法内this类型丢失
复杂类型场景过度依赖类型断言（应优先使用泛型参数）

问题解答

组合式API通过函数式编程范式强化类型推导：

ref/reactive等工厂函数通过泛型参数传递类型，TS根据初始值自动推断
Setup函数上下文变量呈线性声明，类型推导链路完整，避免Options API的配置对象类型分裂
响应式变量类型自动展开（如Ref<T>访问时自动解包为T），而Options API依赖组件实例合并类型

对比示例：Options API需在data()显式声明返回类型并维护methods中的this类型，而组合式API通过变量定义自然携带类型信息。

解决方案

 // 组合式API类型推导示例
import { defineComponent, ref, reactive } from 'vue'

interface User {
 name: string
 age: number
}

export default defineComponent({
 setup() {
 // 基础类型自动推导为Ref<string>
 const username = ref('')
 
 // 复杂对象显式泛型
 const user = reactive<User>({
 name: 'John',
 age: 30
 })

 // 自动推导出( (e: Event) => void
 const handleChange = (e: Event) => {
 username.value = (e.target as HTMLInputElement).value
 }

 return { username, handleChange }
 }
})

优化点：

defineProps/defineEmits类型声明

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下能力维度：

Vue3组合式API的深度应用：考察对<script setup>语法糖中类型声明机制的理解
TypeScript高级类型运用：评估接口继承、联合类型等特性在组件通信中的实际应用
类型系统与运行时行为的结合：验证类型定义如何影响组件API的设计与校验

具体技术评估点：

泛型语法在defineProps/defineEmits中的正确使用
接口继承实现类型扩展的能力
字面量类型在组件属性校验中的应用
默认值处理与类型系统的协同
事件发射器的类型安全约束

技术解析

关键知识点

组件Props类型声明（泛型 > 接口继承 > 字面量联合）
事件发射器类型约束（函数重载 > 索引签名）
默认值处理（withDefaults）

原理剖析

在<script setup>中，defineProps和defineEmits是编译器宏，通过泛型参数传递类型信息。TypeScript编译器会解析这些类型参数并生成运行时类型校验逻辑。当使用接口继承时，类型系统会通过结构化类型检查实现类型兼容。

事件发射器的类型定义采用函数调用签名形式，每个事件对应一个函数类型声明，参数列表需严格匹配发射时的参数结构。字面量联合类型则通过枚举约束实现编译时校验。

常见误区

混淆运行时校验与编译时类型检查
忘记使用withDefaults处理默认值导致类型不匹配
错误使用函数参数解构破坏类型推断
事件名采用非字面量类型导致类型失效

问题解答

在<script setup>中通过泛型定义类型化props/emits：

 <script setup lang="ts">
// 基础接口
interface BaseProps {
 /** 组件唯一标识 */
 id: string
}

// 扩展接口 + 字面量类型
interface ComponentProps extends BaseProps {
 /** 用户姓名（必填） */
 name: string
 /** 用户年龄（默认25） */
 age?: number
 /** 状态标识 */
 status: 'loading' | 'success' | 'error'
}

// 带默认值的类型化props
const props = withDefaults(defineProps<ComponentProps>(), {
 age: 25,
 status: 'loading'
})

// 事件类型声明（函数重载方式）
interface EmitEvents {
 (e: 'dataChange', payload: { id: string }): void
 (e: 'submit'): void
}

const emit = defineEmits<EmitEvents>()
</script>

解决方案

编码示例

 // 复杂类型校验示例
interface AdvancedProps {
 /** 动态表单配置 */
 config: {
 fields: Array<{
 name: string
 inputType: 'text' | 'number' | 'date'
 }>
 }
}

// 组合接口继承
interface FormProps extends AdvancedProps, BaseProps {
 /** 提交按钮文本 */
 submitText?: string
}

// 事件发射器扩展
type FormEmits = {
 (e: 'formSubmit', values: Record<string, unknown>): void
 (e: 'validationFail', errors: string[]): void
}

可扩展性建议

类型复用：通过类型导出实现跨组件复用类型定义
性能优化：复杂对象类型使用Readonly修饰符避免不必要的响应式转换
设备适配：对低端设备可分离基础类型和扩展类型按需加载

深度追问

如何实现嵌套对象的深度类型校验？

Vue3的IE11兼容性方案

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度：Vue工程化配置能力、浏览器兼容性处理经验、构建工具链理解深度
技术评估点：

对ES6+特性向后兼容方案的掌握（Proxy/enerator-runtime）
Babel配置与polyfill机制的实际运用能力
对node_modules依赖转换策略的理解（transpileDeps工作原理）
IE11特有兼容问题的处理经验（CSS变量/对象API）
构建体积与兼容方案的权衡意识

技术解析

关键知识点

core-js > @babel/preset-env > browserslist配置优先级
@vue/cli构建链 > transpileDeps实现机制 > useBuiltIns配置策略

原理剖析

Vue3默认使用Proxy实现响应式，但IE11不支持且无法polyfill。兼容方案需：

替换为@vue/composition-api + reactivity模块的非Proxy实现
通过core-js提供缺失的ES6+ API（Map/Set/Promise等）
babel.config.js配置presets使用useBuiltIns: 'usage'自动按需注入polyfill
transpileDeps通过白名单机制将node_modules中的ES6+依赖强制经过Babel转译

 // babel.config.js
module.exports = {
 presets: [
 ['@vue/cli-plugin-babel/preset', {
 useBuiltIns: 'usage', // 按需注入polyfill
 corejs: 3 // 指定core-js版本
 }]
 ]
}

常见误区

误认为proxy-polyfill可完整实现Proxy（仅支持部分功能）
未配置transpileDeps导致第三方库ES6语法未转换
core-js全局污染与按需加载的配置混淆
忽略CSS自定义属性的postcss-custom-properties兼容处理

问题解答

Polyfill配置步骤：

安装core-js@3、regenerator-runtime

入口文件顶部引入：

 import 'core-js/stable' 
import 'regenerator-runtime/runtime'

使用@babel/plugin-transform-runtime减少重复注入

Vue3移除API的替代方案

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

该题目主要考察以下核心能力维度：

框架演进理解：是否掌握Vue3的设计理念与破坏性变更
API迁移能力：针对已废弃特性能否给出官方推荐替代方案
架构设计思维：理解不同状态管理方案的适用场景及优劣对比

具体技术评估点：

过滤器（Filters）的现代化替代方案
$children的替代实现方式
事件总线（Event Bus）模式的问题分析
状态管理方案的选型依据

技术解析

关键知识点

Composition API > 过滤器替代
ref/scoped slots > $children替代
Provide/estore > 事件总线替代

原理剖析

Vue3移除过滤器的核心逻辑在于提升模板的JavaScript表达能力。通过方法调用（{{ formatDate(date) }}）或计算属性，开发者可以获得类型安全与更好的TS支持。$children的移除源于其不可靠的组件树遍历特性，改用ref获取具体子组件实例可避免隐式依赖。

事件总线的问题突出表现在响应式追踪失效和内存泄漏风险。基于Provide/Inject的依赖注入模式通过清晰的组件层级关系进行通信，而Pinia等状态库通过集中式store管理跨组件状态，配合Vue Devtools可实现完整的状态变更追溯。

常见误区

错误地在组合式函数中尝试使用过滤器
通过$parent逆向操作破坏组件封装性
在大型项目中滥用事件总线导致调试困难

问题解答

Vue3官方推荐的API替代方案如下：

过滤器（Filter）：改用方法调用或计算属性。例如将{{ text | uppercase }}改写为{{ uppercase(text) }}，或在setup中使用computed处理复杂逻辑
$children：使用模板ref获取特定子组件引用，或通过作用域插槽传递数据。跨层级通信推荐provide/inject
事件总线：改用provide/inject传递回调函数，或采用Pinia进行状态管理。事件总线因缺乏响应式追踪、易引发内存泄漏，且不利于维护而被废弃

解决方案

事件总线替代示例

 // 使用Pinia状态管理
import { defineStore } from 'pinia'

const eventStore = defineStore('events', {
 state: () => ({
 listeners: {}
 }),
 actions: {
 on(event, callback) {
 (this.listeners[event] ||= []).push(callback)
 },
 emit(event, ...args) {
 this.listeners[event]?.forEach(fn => fn(...args))
 }
 }
})

// 组件中使用
const store = eventStore()
store.on('refresh', () => {...})
store.emit('refresh')

扩展建议

低端设备：采用事件节流并及时清理监听器
超大应用：结合Pinia的模块化store进行状态拆分
SSR场景：使用Symbol作为provide的key避免命名冲突

深度追问

如何防止provide/inject的滥用导致组件耦合？ 采用类型约束与接口声明，通过TS确保注入内容的契约性

组合式API+Teleport实现Modal

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

核心能力维度

组合式API应用：考察逻辑复用能力与响应式状态管理
Teleport机制理解：评估对DOM挂载位置与样式作用域的掌握
可访问性实践：验证键盘交互与焦点管理的规范化实现
动画集成方案：测试过渡动画与组件生命周期的协调能力

技术评估点

Teleport的DOM挂载策略及其对CSS层叠上下文的影响
组合式API中状态管理与组件通信的合理抽象
事件监听的绑定/解绑与内存泄漏防范
符合WAI-ARIA标准的焦点控制实现
CSS Transition与组件挂载/卸载时序的协同

技术解析

关键知识点

Teleport > Composition API > Focus Trap > Keyboard Events > CSS Transition

原理剖析

Teleport机制：将模态框渲染至<body>末端，避免父组件position: relative导致的定位失效。通过to属性指定目标容器，保持全局样式稳定性
响应式控制：使用ref管理开闭状态，通过defineEmits暴露open/close事件。采用v-model语法糖实现双向绑定
事件管理：组件挂载时注册keydown监听，处理ESC关闭。卸载时通过removeEventListener防止内存泄漏。使用tabindex="-1"与focus-trap库实现焦点锁定
动画集成：<Transition>组件配合enter-active-class实现入场/离场动画。注意duration属性与CSS动画时间的同步，防止DOM提前卸载

常见误区

未在onUnmounted清除事件监听导致内存泄漏
直接修改props违反单向数据流原则
使用setTimeout处理动画导致时序错乱
忽略role="dialog"等ARIA属性影响可访问性

问题解答

实现步骤如下：

Teleport挂载：将模态框内容传送至body末端，避免CSS层级问题
组合式状态：使用ref控制显隐状态，通过defineEmits触发状态变更
键盘监听：在onMounted注册ESC键监听，onUnmounted移除
焦点管理：使用autofocus属性与focus-trap-vue库实现焦点锁定
动画过渡：<Transition>包裹模态内容，配置enter-active等动画类

解决方案

 // Modal.vue
<template>
 <Teleport :to="target">
 <Transition name="modal" @after-leave="$emit('close')">
 <div v-if="isOpen" 
 role="dialog"
 class="modal-wrap"
 @keydown.esc="handleClose">
 <div class="modal-content">
 <slot />
 </div>
 </div>
 </Transition>
 </Teleport>
</template>

<script setup>
import { ref, onMounted, onUnmounted } from 'vue'

const props = defineProps({
 modelValue: Boolean,
 target: { type: String, default: 'body' }
})
const emit = defineEmits(['update:modelValue'])

const isOpen = ref(false)

// 控制显隐同步
watch(() => props.modelValue, val => isOpen.value = val)
watch(isOpen, val => emit('update:modelValue', val))

// ESC关闭处理
const handleClose = () => isOpen.value = false

// 键盘监听
const keyHandler = (e) => {
 if (e.key === 'Escape') handleClose()
}

onMounted(() => window.addEventListener('keydown', keyHandler))
onUnmounted(() => window.removeEventListener('keydown', keyHandler))
</script>

<style>
.modal-enter-active, .modal-leave-active {
 transition: opacity 0.3s ease;
}
.modal-enter-from, .modal-leave-to {
 opacity: 0;
}
</style>

可扩展性建议

动态挂载点：通过targetprop支持自定义挂载容器
动画增强：集成animate.css实现多样化过渡效果
全局状态：结合Pinia管理多模态框的叠加状态
性能优化：添加lazy修饰符实现按需加载模态内容

深度追问

追问1：如何实现点击外部关闭？

提示：使用@click.self判断点击区域

组件库Tree shaking优化策略

Tue, 04 Mar 2025 07:00:31 +0000

考察点分析

本题主要考察以下核心能力：

Tree Shaking机制理解：能否准确阐述ES模块静态分析原理及其与打包工具的配合机制
组件库架构设计：是否掌握模块化导出方案，包括多入口、分包策略等工程化实践
构建工具配置能力：对Vite/Rollup配置项的掌握程度，特别是preserveModules等高级优化配置

具体技术评估点：

ES模块导出规范与CommonJS差异
Rollup的preserveModules模式工作原理
副作用标注与package.json配置
组件目录结构与构建输出的映射关系

技术解析

关键知识点

ES Module静态结构 > Rollup模块保留 > 副作用标注
组件独立分包 > 构建输出优化

原理剖析

Tree Shaking依赖于ESM的静态语法特征，打包工具通过模块依赖图谱分析未被引用的导出。当组件库采用export const Component形式导出时，Rollup能精准识别未使用代码。配合preserveModules: true配置，会保留原始模块结构而非打包成单一chunk，保障按需引入的可行性。

常见误区

误用export default导致导出分析失效
未配置sideEffects: false阻碍优化
组件耦合导致的隐性依赖（如全局样式）

问题解答

实现Tree Shaking需遵循以下步骤：

模块规范：组件使用具名导出

 // src/components/Button/index.ts
export const Button = defineComponent({...})

入口聚合：主文件二次导出

 // src/index.ts
export * from './components/Button'
export * from './components/Input'

Vite配置：

 // vite.config.js
export default defineConfig({
 build: {
 lib: {
 entry: 'src/index.ts',
 formats: ['es']
 },
 rollupOptions: {
 external: ['vue'],
 output: {
 preserveModules: true, // 保留模块结构
 dir: 'dist', // 分包输出目录
 entryFileNames: '[name].js' // 按源文件名生成
 }
 }
 }
})

package.json声明：

composition api 与 options api 的区别

Tue, 04 Mar 2025 05:09:42 +0000

开始之前

Composition API 可以说是Vue3的最大特点，那么为什么要推出Composition Api，解决了什么问题？

通常使用Vue2开发的项目，普遍会存在以下问题：

代码的可读性随着组件变大而变差
每一种代码复用的方式，都存在缺点
TypeScript支持有限

以上通过使用Composition Api都能迎刃而解

正文

一、Options Api

Options API，即大家常说的选项API，即以vue为后缀的文件，通过定义methods，computed，watch，data等属性与方法，共同处理页面逻辑

如下图：

可以看到Options代码编写方式，如果是组件状态，则写在data属性上，如果是方法，则写在methods属性上…

用组件的选项 (data、computed、methods、watch) 组织逻辑在大多数情况下都有效

然而，当组件变得复杂，导致对应属性的列表也会增长，这可能会导致组件难以阅读和理解

二、Composition Api

在 Vue3 Composition API 中，组件根据逻辑功能来组织的，一个功能所定义的所有 API 会放在一起（更加的高内聚，低耦合）

即使项目很大，功能很多，我们都能快速的定位到这个功能所用到的所有 API

三、对比

下面对Composition Api与Options Api进行两大方面的比较

逻辑组织
逻辑复用

逻辑组织

Options API

假设一个组件是一个大型组件，其内部有很多处理逻辑关注点（对应下图不用颜色）

可以看到，这种碎片化使得理解和维护复杂组件变得困难

选项的分离掩盖了潜在的逻辑问题。此外，在处理单个逻辑关注点时，我们必须不断地“跳转”相关代码的选项块

Compostion API

而Compositon API正是解决上述问题，将某个逻辑关注点相关的代码全都放在一个函数里，这样当需要修改一个功能时，就不再需要在文件中跳来跳去

下面举个简单例子，将处理count属性相关的代码放在同一个函数了

 function useCount() {
 let count = ref(10);
 let double = computed(() => {
 return count.value * 2;
 });

 const handleConut = () => {
 count.value = count.value * 2;
 };

 console.log(count);

 return {
 count,
 double,
 handleConut,
 };
}

组件上中使用count

vue3 的设计目标是什么？做了哪些优化？

Tue, 04 Mar 2025 05:09:42 +0000

一、设计目标

不以解决实际业务痛点的更新都是耍流氓，下面我们来列举一下Vue3之前我们或许会面临的问题

随着功能的增长，复杂组件的代码变得越来越难以维护
缺少一种比较「干净」的在多个组件之间提取和复用逻辑的机制
类型推断不够友好
bundle的时间太久了

而 Vue3 经过长达两三年时间的筹备，做了哪些事情？

我们从结果反推

更小
更快
TypeScript支持
API设计一致性
提高自身可维护性
开放更多底层功能

一句话概述，就是更小更快更友好了

更小

Vue3移除一些不常用的 API

引入tree-shaking，可以将无用模块“剪辑”，仅打包需要的，使打包的整体体积变小了

更快

主要体现在编译方面：

diff算法优化
静态提升
事件监听缓存
SSR优化

下篇文章我们会进一步介绍

更友好

vue3在兼顾vue2的options API的同时还推出了composition API，大大增加了代码的逻辑组织和代码复用能力

这里代码简单演示下：

存在一个获取鼠标位置的函数

 import { toRefs, reactive } from 'vue';
function useMouse(){
 const state = reactive({x:0,y:0});
 const update = e=>{
 state.x = e.pageX;
 state.y = e.pageY;
 }
 onMounted(()=>{
 window.addEventListener('mousemove',update);
 })
 onUnmounted(()=>{
 window.removeEventListener('mousemove',update);
 })

 return toRefs(state);
}

我们只需要调用这个函数，即可获取x、y的坐标，完全不用关注实现过程

vue3 实现一个 Modal 组件设计思路与流程分析

Tue, 04 Mar 2025 05:09:42 +0000

一、组件设计

组件就是把图形、非图形的各种逻辑均抽象为一个统一的概念（组件）来实现开发的模式

现在有一个场景，点击新增与编辑都弹框出来进行填写，功能上大同小异，可能只是标题内容或者是显示的主体内容稍微不同

这时候就没必要写两个组件，只需要根据传入的参数不同，组件显示不同内容即可

这样，下次开发相同界面程序时就可以写更少的代码，意义着更高的开发效率，更少的 Bug和更少的程序体积

二、需求分析

实现一个Modal组件，首先确定需要完成的内容：

遮罩层
标题内容
主体内容
确定和取消按钮

主体内容需要灵活，所以可以是字符串，也可以是一段 html 代码

特点是它们在当前vue实例之外独立存在，通常挂载于body之上

除了通过引入import的形式，我们还可通过API的形式进行组件的调用

还可以包括配置全局样式、国际化、与typeScript结合

三、实现流程

首先看看大致流程：

目录结构
组件内容
实现 API 形式
事件处理
其他完善

目录结构

Modal组件相关的目录结构

 ├── plugins
│ └── modal
│ ├── Content.tsx // 维护 Modal 的内容，用于 h 函数和 jsx 语法
│ ├── Modal.vue // 基础组件
│ ├── config.ts // 全局默认配置
│ ├── index.ts // 入口
│ ├── locale // 国际化相关
│ │ ├── index.ts
│ │ └── lang
│ │ ├── en-US.ts
│ │ ├── zh-CN.ts
│ │ └── zh-TW.ts
│ └── modal.type.ts // ts类型声明相关

因为 Modal 会被 app.use(Modal) 调用作为一个插件，所以都放在plugins目录下

vue3 的性能提升主要体现在哪些方面？

Tue, 04 Mar 2025 05:09:42 +0000

一、编译阶段

回顾Vue2，我们知道每个组件实例都对应一个 watcher 实例，它会在组件渲染的过程中把用到的数据property记录为依赖，当依赖发生改变，触发setter，则会通知watcher，从而使关联的组件重新渲染

试想一下，一个组件结构如下图

 <template>
 <div id="content">
 <p class="text">静态文本</p>
 <p class="text">静态文本</p>
 <p class="text">{{ message }}</p>
 <p class="text">静态文本</p>
 ...
 <p class="text">静态文本</p>
 </div>
</template>

可以看到，组件内部只有一个动态节点，剩余一堆都是静态节点，所以这里很多 diff 和遍历其实都是不需要的，造成性能浪费

因此，Vue3在编译阶段，做了进一步优化。主要有如下：

diff算法优化
静态提升
事件监听缓存
SSR优化

diff算法优化

vue3在diff算法中相比vue2增加了静态标记

关于这个静态标记，其作用是为了会发生变化的地方添加一个flag标记，下次发生变化的时候直接找该地方进行比较

下图这里，已经标记静态节点的p标签在diff过程中则不会比较，把性能进一步提高

关于静态类型枚举如下

 export const enum PatchFlags {
 TEXT = 1,// 动态的文本节点
 CLASS = 1 << 1, // 2 动态的 class
 STYLE = 1 << 2, // 4 动态的 style
 PROPS = 1 << 3, // 8 动态属性，不包括类名和样式
 FULL_PROPS = 1 << 4, // 16 动态 key，当 key 变化时需要完整的 diff 算法做比较
 HYDRATE_EVENTS = 1 << 5, // 32 表示带有事件监听器的节点
 STABLE_FRAGMENT = 1 << 6, // 64 一个不会改变子节点顺序的 Fragment
 KEYED_FRAGMENT = 1 << 7, // 128 带有 key 属性的 Fragment
 UNKEYED_FRAGMENT = 1 << 8, // 256 子节点没有 key 的 Fragment
 NEED_PATCH = 1 << 9, // 512
 DYNAMIC_SLOTS = 1 << 10, // 动态 solt
 HOISTED = -1, // 特殊标志是负整数表示永远不会用作 diff
 BAIL = -2 // 一个特殊的标志，指代差异算法
}

静态提升

Vue3中对不参与更新的元素，会做静态提升，只会被创建一次，在渲染时直接复用

proxy api 与 defineProperty API 比较

Tue, 04 Mar 2025 05:09:42 +0000

一、Object.defineProperty

定义：Object.defineProperty() 方法会直接在一个对象上定义一个新属性，或者修改一个对象的现有属性，并返回此对象

为什么能实现响应式

通过defineProperty 两个属性，get及set

属性的 getter 函数，当访问该属性时，会调用此函数。执行时不传入任何参数，但是会传入 this 对象（由于继承关系，这里的this并不一定是定义该属性的对象）。该函数的返回值会被用作属性的值

属性的 setter 函数，当属性值被修改时，会调用此函数。该方法接受一个参数（也就是被赋予的新值），会传入赋值时的 this 对象。默认为 undefined

下面通过代码展示：

定义一个响应式函数defineReactive

 function update() {
 app.innerText = obj.foo
}

function defineReactive(obj, key, val) {
 Object.defineProperty(obj, key, {
 get() {
 console.log(`get ${key}:${val}`);
 return val
 },
 set(newVal) {
 if (newVal !== val) {
 val = newVal
 update()
 }
 }
 })
}

调用defineReactive，数据发生变化触发update方法，实现数据响应式

 const obj = {}
defineReactive(obj, 'foo', '')
setTimeout(()=>{
 obj.foo = new Date().toLocaleTimeString()
},1000)

在对象存在多个key情况下，需要进行遍历

Vue3.0中Treeshaking特性

Tue, 04 Mar 2025 05:09:42 +0000

一、是什么

Tree shaking 是一种通过清除多余代码方式来优化项目打包体积的技术，专业术语叫 Dead code elimination

简单来讲，就是在保持代码运行结果不变的前提下，去除无用的代码

如果把代码打包比作制作蛋糕，传统的方式是把鸡蛋（带壳）全部丢进去搅拌，然后放入烤箱，最后把（没有用的）蛋壳全部挑选并剔除出去

而treeshaking则是一开始就把有用的蛋白蛋黄（import）放入搅拌，最后直接作出蛋糕

也就是说，tree shaking 其实是找出使用的代码

在Vue2中，无论我们使用什么功能，它们最终都会出现在生产代码中。主要原因是Vue实例在项目中是单例的，捆绑程序无法检测到该对象的哪些属性在代码中被使用到

 import Vue from 'vue'
 
Vue.nextTick(() => {})

而Vue3源码引入tree shaking特性，将全局 API 进行分块。如果您不使用其某些功能，它们将不会包含在您的基础包中

 import { nextTick, observable } from 'vue'
 
nextTick(() => {})

二、如何做

Tree shaking是基于ES6模板语法（import与exports），主要是借助ES6模块的静态编译思想，在编译时就能确定模块的依赖关系，以及输入和输出的变量

Tree shaking无非就是做了两件事：

编译阶段利用ES6 Module判断哪些模块已经加载
判断那些模块和变量未被使用或者引用，进而删除对应代码

下面就来举个例子：

通过脚手架vue-cli安装Vue2与Vue3项目

 vue create vue-demo

Vue2 项目

组件中使用data属性

 <script>
 export default {
 data: () => ({
 count: 1,
 }),
 };
</script>

对项目进行打包，体积如下图

Vue3 on ZiYang FrontEnd Interview

Vue3与Vue2响应式原理差异

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

解决方案 link

Proxy替代Object.defineProperty的原因

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

reactive与ref的核心区别

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

问题解答 link

深度追问 link

reactive处理基本类型的限制

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

解决方案 link

watch与watchEffect的差异

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

Options API与Composition API架构对比

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

组合式API常用方法解析

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

解决方案 link

编码示例 link

优化建议 link

深度追问 link

script setup语法糖的优势

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

组合式API生命周期变化

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

解决方案 link

代码示例 link

可扩展性建议 link

深度追问 link

组合式API逻辑复用实现

考察点分析 link

技术解析 link

关键知识点 link

原理剖析 link

常见误区 link

问题解答 link

Vue3的Tree shaking实现原理

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

解决方案

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

考察点分析

技术解析

关键知识点

原理剖析

问题解答

深度追问

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

解决方案

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

解决方案

编码示例

优化建议

深度追问

考察点分析

技术解析

关键知识点

原理剖析

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

解决方案

代码示例

可扩展性建议

深度追问

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

考察点分析

技术解析

关键知识点

原理剖析

常见误区

问题解答

解决方案

架构对比

编译器优化

考察点分析

技术解析

关键知识点