最近带了不少候选人面试，发现一个有意思的现象：Vue 面试题这道关，卡住的往往不是基础差的人，而是那些“背了一堆题却不知道怎么答”的人。Vue 框架本身不算难上手，但面试时问的往往不是“这个 API 怎么用”，而是背后的设计思路、取舍逻辑和边界情况。这篇文章我不想搞成一份题库的机械罗列，而是从考官视角，聊聊 Vue 面试题到底在筛什么，以及每一类高频题背后的解题框架是什么。无论你是准备求职还是有几年经验想补补盲区，按这条线梳理一遍，应该会比刷几十道题更有底。

写这篇文章之前，我做了下分类。Vue 面试题表面上是知识点拼盘，实际上考的是三个维度：原理深度、业务落地能力和工程化思维。基于这个判断，我会把高频题目拆成几个章节来展开，每个问题都会给回答思路，而不是标准答案。毕竟面试官最反感的就是背答案。

1. Vue 面试的考点全景与考官的真实意图

1.1 Vue 面试到底在考什么

很多人准备 Vue 面试题，第一反应是收集一堆“有没有被问过的题”清单，然后对着背。这个思路从根上就偏了。面试官在提任何一个 Vue 问题时，想得到的都不是一个孤立的知识点，而是你能否通过这个知识点，展现自己平时写代码时有没有想过“为什么”。

举个例子。“Vue 3 的响应式原理是什么”这道题，初级面会问，高级面也会问，但考官期待的人群完全不一样。对初级，能说清楚 Proxy 和 Object.defineProperty 的区别就及格；对高级，如果只说区别而不谈对编译期优化、性能影响和框架设计权衡，大概率会被打断追问。

根据我观察到的真实面试记录，Vue 相关的提问通常遵循一条潜规则：不问你有没有用过某个 API，而是问你在什么场景下用、为什么用它、遇到坑怎么处理。比如“keep-alive 的原理”，你只回答“可以缓存组件”完全不够，得说出它内部维护了一个 LRU 缓存，并且通过 include/exclude 控制缓存策略，这才算过关。

所以准备 Vue 面试题，第一步不是刷题，是调整心态。把“背答案”换成“搞懂原理，再组织表达”，效果会好非常多。

1.2 不同经验级别的考查侧重点

Vue 面试题不是一个单一难度的题库，它天然分档。我建议你也按自己的经验段位来准备，不要越级去背一大把用不上的偏题。

初级（1-3年）侧重基础使用与常见 API 理解：生命周期执行顺序、组件通信方式、 v-model 用法、 computed 和 watch 区别。这些题目的核心是确认你在真实的项目里写过 Vue，而不是只看了文档。

中级（3-5年）开始侧重原理和性能：虚拟 DOM 的 diff 过程、 nextTick 运行机制、响应式依赖收集的细节、依赖追踪的边界情况（比如数组索引的处理、新增属性为什么不是响应式）。同时会穿插场景题，比如“一个表格里几百条数据，每 500ms 更新一次，你会怎么优化”。

高级（5年以上）则更侧重架构和方案选型：状态管理用 Vuex 还是 Pinia、微前端下 Vue 实例怎么隔离、超大项目怎么拆分业务与公共逻辑、 SSR 的落地效果。到了这个级别，单纯的“知道”已经不重要了，重要的是“在复杂环境里能不能做判断”。

我见过不少候选人拿高级题库去准备初级面试，结果基础题答得飞快，一到工程化落地的细节就露馅，反而拉低了整体评价。按自己的实际水平聚焦式复习，比全面撒网有效得多。

1.3 考官眼中“好答案”的三个特征

既然聊到了考官视角，就顺手分享一下我评判 Vue 面试题答案好坏的标准，这也是这些年参与面试总结出来的。

第一个特征是结论先行。面试官问你问题，不希望听你在那绕，而是要你先给一个明确结论，再逐步展开。比如“为什么 v-for 需要 key”，第一句就该说“key 是虚拟 DOM diff 时的唯一标识，决定节点复用策略”。而不是先讲虚拟 DOM 是什么。

第二个特征是能联系到真实场景。“计算属性为什么不能异步”，标准说法是它依赖响应式数据做同步缓存，如果里面发请求会拿到一个 pending 状态的 Promise，且缓存逻辑会失效。如果你能补一句“我在项目里用它做购物车总价计算，数据一变 UI 立刻同步，所以它天然适合同步派生”，这道题的分数就上去了。

第三个特征是能主动讲出边界和代价。每项技术都有不完美的角落，愿意主动讲缺点的人，通常才是真正用过的人。比如 Vue3 的 Proxy 虽然解决了新增删除属性的响应式问题，但在某些低版本环境里对 Proxy 的依赖也带来了兼容性消耗。能说出这种权衡，说明你是在“用框架”而不是“被框架用”。

2. 高频核心原理题：答题框架与思路拆解

2.1 响应式原理：从 defineProperty 到 Proxy 的差异迁移

这一组题基本是 Vue 面试题里出场率最高的。最常见的一个变体就是“Vue2 和 Vue3 的响应式实现有什么区别”，或者“Vue3 为什么用 Proxy 替代 defineProperty”。

回答这个问题的第一步，是把底层机制讲清楚。Vue2 的响应式基于 Object.defineProperty，核心逻辑是遍历已有属性，用 getter 做依赖收集、setter 做派发更新。它的问题有几个：只能拦截已有属性，新增或删除属性时数据不是响应式的；对数组的监听只能靠重写七个数组方法来实现；深度监听需要递归遍历，一次性开销大。

Vue3 换成 Proxy 后，整个拦截粒度从“属性级”提升到“对象级”。不管访问还是修改，都是通过 Proxy 的 get 和 set 处理器统一处理，新增删除属性天然被拦截到。另一个关键点是 Proxy 在实现上是惰性的，访问到某个嵌套对象时才为它创建响应式代理，而不是在初始化阶段递归全部嵌套层。这样能明显减少初始化时的开销。

讲完这些基本点，再补一层“坑和注意”就更有竞争力。比如 Vue2 中为什么有 Vue.set，因为新增属性根本不会触发 setter，必须用专门 API 帮它补上 dep 和 observe。Vue3 中虽然新增属性没问题，但解构赋值时仍会丢失响应式，因为解构过程是基于普通对象取值，不经过 Proxy 的 get 陷阱。这里顺带提一句 toRefs 就是用来解决这个场景的，会显得你比一般候选人更能动手验证。

我经常建议候选人准备一个 30 秒左右的精简版本回答框架：先抛出核心差异（属性级 vs 对象级），再说明设计结果（解决了什么问题），最后给出一个自行体会过的坑（比如解构丢失响应式）。这样面试官不需要追问，就已经能判断你是真懂的。

2.2 虚拟 DOM 与 diff 算法：不要只会背“同层比较”

虚拟 DOM 相关问题通常以两种形态出现：要么问“虚拟 DOM 是什么，为什么要用它”，要么问“diff 过程是怎么走的”。前者考察理解，后者考察细节。

第一问的回答不要站在“JS 模拟 DOM 结构”这个层面就停了。虚拟 DOM 存在的真正意义不是让你“不操作 DOM”，而是把视图更新变成一个“用数据生成对象树、再做对比、最后最小化更新真实 DOM”的流程。它带来的直接好处，是把渲染逻辑和真实环境解耦，所以不仅可以跑在浏览器里，也能跑在服务端（SSR），还能对接小程序这类不放真实 DOM 的环境。

第二问要能说出 diff 的完整流程，但不建议死记硬背每个函数名。核心逻辑是：只进行同层级比较，不做跨层级复用；每个节点比较时先看标签名是否一致，再看 key 是否相同；如果都没匹配上，就把它当作新节点进行创建插入。这里有个关键点，diff 真的不是“逐节点暴力比对”，Vue 在这里还有一个优化策略，就是利用 key 来快速识别哪些节点只是移动了位置，这样才能撑起长列表的高效更新。

回答这类问题时，我建议举一个具体例子来增强说服力。比如“一个数组列表从 A B C D 变成 B A C D，如果 key 是唯一 id，diff 时只需要做节点的位置移动；如果 key 是数组下标，B 和 A 的索引都变了，可能会触发不必要的重建”。这种生产环境真实遇到的场景，比背十句术语更有分量。

2.3 computed 与 watch 的边界问题

“computed 和 watch 的区别”这道题，属于送分题的问法，但也是大型翻车现场。狂背“computed 有缓存、watch 没有缓存”这种回答，勉强能过初级，但拦不住经验丰富的面试官往下深挖。

首先要说清楚各自的定位：computed 是“由其他响应式数据派生出来的新值”，核心是缓存，依赖不变就不会重新计算；watch 是“监听一个数据变化，然后执行一个副作用”，比如请求接口、操作 DOM、写日志。用一个生活化的类比，computed 像计算器，你按的加法和数字没变，它能记住结果不会反复算；watch 像门卫，只有有人进来或者出去时才会启动检查。

其次要能处理边界场景。比如“computed 里能不能发请求？”不能，因为计算属性必须保持纯函数性质，如果里面发请求，第一次访问可能拿到 undefined，而且异步回来的数据不会触发新的依赖更新，缓存会失效。再比如“watch 能不能监听一个不存在的属性？”可以，只要点路径合法，它会在 getter 访问这个属性时建立依赖关系。

还有一个高频追问是：“如果需要在多个数据变化后做统一处理，应该用 computed 还是 watch？”这个问题本质是考你对“派生数据 vs 副作用”的理解。多个数据共同派生出一个新状态，是 computed 的主场；多个数据变化后各自触发不同的副作用，watch 更合适。你要能接住这种场景化追问，这一题才算答完。

2.4 nextTick 究竟在等什么

nextTick 是另一个绕不开的考点。常见问法是“为什么改完数据后马上拿 DOM 拿不到最新结果”，以及“nextTick 的原理是什么”。

答案的核心在于 Vue 的视图更新是异步的。当你修改响应式数据时，Vue 不会立刻去更新 DOM，而是先把这个 watcher 推入一个队列，再去重去重；等当前宏任务做完了，在下一个微任务阶段统一刷新。这个设计一方面避免同一事件循环里多次修改数据导致的重复渲染，另一方面也保证了渲染资源的高效利用。

nextTick 本身做的事情，就是把一个回调放进微任务队列（或再降级方案里的宏任务），让它在 DOM 批量更新之后执行。用大白话讲，nextTick 就是“我帮你预约了一个‘等 Vue 干完活之后’再通知你的电话”。

这个题的加分回答在于谈到原理的降级策略。nextTick 内部并不是只写死一种 Promise，它有降级链：Promise.then -> MutationObserver -> setImmediate -> setTimeout。为什么会有这个设计？因为在某些非常老的环境里 Promise 不可用或者整栈对微任务支持不完整，框架为了保证所有环境都能工作，才做了多级能力检测。有候选人能聊到这个细节，几乎必然会让面试官眼前一亮。

3. 组件化与状态管理：不是背 API，是拼理解

3.1 组件通信方式：别只说“爷孙组件用 provide/inject”

组件通信这个考点，几乎每次面试必问。答案本身并不难背，难的是你能不能快速选出“在这个场景下最合适的方式”。

我把组件通信的方案整理了一下，大致分为以下这些：

• props / emit：父传子和子传父最基础单一来源
• v-model：对表单类组件做父子双向数据同步
• provide / inject：深层组件跨级传递，不用层层传 props
• $refs / $children：直接用实例访问子组件的方法或属性
• $attrs / $listeners：属性和监听器的透传，特别是写高阶组件时很有用
• event bus / mitt：跨组件无血缘关系时的简单通信
• 状态管理（Vuex / Pinia）：全局共享的状态集中管理

拿“爷孙组件通信”来举例，如果你首先想到的是 props 一层层传下去，也不算错，但很蠢。因为中间层只是转发，不消费这些数据，传递路径根本没有意义。这时候用 provide / inject 就清晰很多，爷爷直接把自己的数据“供应”出来，孙子组件按需“注入”。这种方式虽然也有响应式问题需要关注，但结构上是合理且直观的。

另一个高频场景题：“项目里有个很大的全局用户信息，很多模块都在读它，应该放哪？”如果各模块之间没有复杂的互相影响，没有数据变更逻辑，一个简单的 reactive 对象挂在全局再导出，是最轻的做法。但如果牵扯到登录态变更、权限更新、多端同步，那就必须放进 Pinia 或 Vuex 统一管起来，否则后面会烂账。这种题的难点不在记忆 API，而在判断“状态复杂度到了什么程度”。

3.2 v-model 的实质与自定义组件上的变化

Vue 面试题里关于 v-model 的题目，一般有两种考法：一是基础用法，二是自定义 v-model 实现。后者对很多人来说有点反直觉，因为平时大多在表单元素上使用，很少自己封装。

先说本质。v-model 是语法糖，在普通输入框上，它等价于绑定 value 属性和监听 input 事件。在组件上，默认等价于传一个 modelValue prop 并监听 update:modelValue 事件。Vue3 把 modelValue 这种命名规则做成了统一约定，这让自定义 v-model 变得特别规整。

假设你要封装一个“省市区选择器”，肯定不能走默认的事件体系，而是想直接用 v-model="selectedRegion" 这种写法。这时你需要在组件里定义 props: ['modelValue']，并在选择发生变化的回调里 emit('update:modelValue', newValue)。外部使用的写法和表单输入框完全一致，这种抽象会让组件的使用体验好很多。

Vue3.4 之后还支持多个 v-model，类似 v-model:title 和 v-model:content，用于一个组件上同时同步两个值。很多人在“是否要拆成两个透传值”这个问题上会犹豫，其实没有必要。只要这两个值之间没有耦合关系，多个 v-model 反而是最直白的表达方式。面试官考这个点，是想确认你封装过真正能复用的业务组件，而不是只知道表单指令的用法。

3.3 Vuex 与 Pinia：状态管理的迁移逻辑

状态管理相关问题，经常和 Vue 版本绑定出现。Vue2 时代默认上 Vuex，Vue3 时代默认上 Pinia。这类题的考察点不是“你用过哪一个”，而是“你知道它们各自的边界在哪里”。

Pinia 相对 Vuex 最大的变化是去掉了 mutation。Vuex 的 mutation 和 action 分开，初衷是让同步变更和异步逻辑分离，并且利用 devtools 做时间旅行调试。但实际团队协作中，很多人分不清“怎么同步变更”和“异步逻辑后变更”的区别，大量代码只是机械地在 action 里 commit 一条 mutation，反而增加了模板代码。

Pinia 直接让 action 承担同步和异步的所有变更职责，概念上更简单。再加上 Pinia 的 store 天然就是响应式对象（基于 reactive 或 ref），也不需要像 Vuex 那样通过 getters 包一层取状态的语法。模块结构也不再需要 namespaced 这种东西，每个 store 本身就是独立模块，用哪个就 use 哪个。

答这个题时，我一般建议带上一句亲测体会：在小型或者中型项目里，Pinia 的上手成本比 Vuex 低非常多；真正的复杂度并不在库本身的 API，而在跨模块共享状态、持久化恢复、服务端数据同步这些业务场景上。这样抛出的信息能让面试官看到你的工程判断力。

3.4 生命周期：背顺序之前先理解为什么

生命周期是 Vue 面试题里最基础的部分，但很多人只记住了名字，不知道顺序背后的设计逻辑。

Vue2 和 Vue3 的生命周期名字有变化，比如 beforeDestroy 改成了 beforeUnmount，destroyed 改成了 unmounted，这个差异一定要记住。组件实例的生命周期本质上是一个从“出生”到“销毁”的过程：设置数据、编译模板、挂载到容器、响应式依赖建立、数据更新触发 re-render、最后执行清理。

面试官经常从两个角度切题。一个角度是父子组件的挂载顺序：父组件 beforeCreate -> created -> 子组件 beforeCreate -> created -> 子组件 mounted -> 父组件 mounted。为什么子组件的挂载要优先于父组件？因为只有当子组件渲染完了，父组件的 DOM 才算是完整拼接成功，否则父组件的 mounted 循环里访问不到子组件占位的真实 DOM。

另一个切入点是 created 和 mounted 的区别。created 阶段实例已经初始化，但还没有渲染 DOM；mounted 阶段渲染完成，真实 DOM 可以访问。于是引发一个经典场景题：“请求数据应该放在 created 还是 mounted 里？”在 Vue2 里 created 调用完全没问题，因为此时 props / data 已经初始化完成；但在 Vue3 配合 SSR 时，推荐把请求尽量放在 mounted 里，或者在服务端用不同的生命周期钩子，避免在服务端环境执行不必要的副作用。能从这个角度答出来，说明你不是背的，是真的被线上环境坑过。

4. 性能优化与应用场景：面试中的必杀技

4.1 响应式数据的性能边界

Vue 面试题走到中后段，很大概率会问你遇到过哪些性能问题，这时候不要只背概念，要把“数据量很大怎么办”这种实战题答透。

一个非常典型的方向是超大数组渲染。比如表格一次性渲染 2000 行，且每行还有动态的计算列。这时候如果用 computed 对整个列表做筛选或汇总，每次数据更新时都会重新计算，计算量大时会有明显卡顿。这种问题的解法有几个层次：能预先聚合的数据尽量通过后端接口返回；前端可以用虚拟滚动只渲染可视区域；如果计算逻辑确实无可避免，可以用函数式组件或用 shallowRef 配合手动 triggerRef 控制更新粒度。

另一个方向是响应式转换的深度陷阱。reactive 是深代理，这意味着一开始使用时很舒心，但如果你把一个特别深的对象放进去，比如一张完整的树形菜单或者一个多层嵌套的配置对象，初始化时并不会立刻全部代理，但每次访问嵌套层时都会动态代理。这在大多数场景下没问题，但极端场景里性能损耗会累积。Vue3 提供的 shallowRef 和 shallowReactive 就是给这类巨型结构准备的。懂得在“灵活”和“性能”之间做取舍，是面试官特别看重的能力。

还有经常被问到的一个点：v-for 里加 :key 是不是越多越好？不是。key 是用来帮助 diff 复用的，不需要的情况下乱加反而会导致节点被错误复用，造成内部状态错乱。典型反面案例是把 index 作为 key，当列表删除一项时，所有后续项目的下标都会变化，导致 key 全部失效，渲染结果和用户期待不一致。比较合理的策略是使用业务唯一 id，或者用内容生成稳定的 hash。

4.2 路由懒加载与异步组件的选型

性能优化问题里，路由懒加载和异步组件是两个几乎绑定的考点。

路由懒加载的本质是代码分割。Vue 项目在打包时如果所有页面都打到一个 JS 文件里，首屏体积会非常恐怖。通过把路由的 component 改成动态 import，即 () => import('/views/xxx.vue')，打包工具就会自动把该组件对应的代码拆成一个独立 chunk，只有访问到这个路由时才去请求执行。

这个点看起来很简单，但面试官会追问“按需加载的 chunk 会不会导致页面跳转的时候白屏闪一下”。这就是实战问题了。应对思路是做路由级 Loading 状态，或者在异步组件外层包一个 Suspense。Vue3 里 Suspense 可以在等待异步依赖时先渲染 fallback 内容，尤其适合在复杂页面初始化时给用户一个可见反馈，而不是看着空白页面发呆。

另一个常见点是 keep-alive。keep-alive 之所以和性能绑定在一起，是因为它缓存的是组件实例本身而不是 DOM 树，这意味着组件状态（滚动位置、表单输入、选中状态）不会丢。面试官问 keep-alive，希望你提到 LRU 缓存策略，即超过 max 值时会淘汰最久没访问的组件。如果你能在项目场景里说明“我缓存了列表页，离开时保留滚动位置，回到列表页时状态还在”，就已经把原理和应用打通了。

4.3 运行时性能的代码层优化细节

Vue 面试题里偏代码实现层面的性能题，通常会给一段不那么优雅的业务代码，让你指出问题并改进。这种题非常考验经验储备。

最常见的优化点之一是计算属性缓存和方法的对比。同一个过滤结果，如果模板里多次调用一个 filterList() 方法，每次渲染都会重新执行函数；如果用 computed，在没有响应式依赖变化的时候直接取缓存，零计算成本。

另一个点是事件监听器的及时清理。组件销毁前不清理全局的事件监听、定时器、观察者，轻则内存泄漏，重则状态错乱。在 Vue3 中，想监听 window resize，一般写进 onMounted 里 addEventListener，在 onBeforeUnmount 里 removeEventListener。要是用 @vueuse/core 的 useEventListener，它会在组件卸载时自动清理，省心很多。

还有一个经常被忽视的细节：列表渲染时避免在模板里写复杂表达式。比如用 v-for 渲染时，模板内部如果有三元运算、字符串拼接、甚至层级嵌套的函数调用，都会在每次渲染时重复执行。这类逻辑建议抽成方法或 computed，代码可读性也会更好。这些点看起来小，但在面试里主动讲出来，会让考官觉得你在真实代码里踩过雷。

5. 面试中的答题策略与实战避坑记录

5.1 “结论-原理-场景-延伸”四步答题法

讲了这么多知识点，最后聊一下具体怎么开口答。很多候选人肚子里有货，但是一到面试现场，表达没有层次，20 分钟过去还没有点到核心，被打断也自然不冤。

我强烈推荐一个四步表达法：结论 → 原理 → 场景 → 延伸。

第一步给结论，就是面试官问你的第一时间，用一两句话把答案的骨架说清楚。比如问“为什么 Vue3 用 Proxy”，结论就是“因为 Proxy 能在对象层面拦截更多操作，解决 Vue2 对新增属性和数组索引监听不到的问题”。

第二步讲原理，深入展开为什么结论成立。这时候可以引入 defineProperty vs Proxy 的技术细节，但不要超过三句话就下沉到代码级，要控制节奏。

第三步落到场景，讲“这个特性 / 这个坑，在我的项目里体现在哪”。还是上面 Proxy 的例子，可以说“我之前用 Vue2 遇到一个表格动态加字段不更新视图的坑，最后用 Vue.set 兜底；Vue3 就从根本上避免了”。

第四步做延伸，简单对比一下相关知识点。比如从 Proxy 延伸到 shallowReactive、从 diff 延伸到 key 优化。延伸不是炫技，是展现知识图谱的深度，让面试官觉得你的理解是网状的而不是点状的。

用这个框架答 Vue 面试题，即使个别细节记不准确，整体逻辑也不会散，这是保住印象分的关键。

5.2 面试中容易翻车的回答习惯

我记录了几个面试过程中高频出现的翻车点，准备 Vue 面试题的朋友可以考虑对照自查。

第一个翻车点是死记硬背概念，不带任何例子。比如回答“计算属性基于响应式依赖缓存”，就这么一句话直接收住。面试官想听的是你对缓存的直观理解，如果你能补上一句“数据没变时多次访问不会执行内部函数，相当于一个带记忆的计算器”，印象分会明显不一样。

第二个翻车点是贬低旧版本或者另一套框架。有人为了表达自己用过新东西，各种数落 Vue2 或者 Vuex 的不好。这种表达方式会让面试官觉得你缺少迁移思维，尤其是很多老项目不可能说升级就升级，是否懂兼容方案才是更重要的事。

第三个翻车点是动手题只给思路不写代码。遇到“手写一个简易响应式”这类题时，一定要把代码写出来，哪怕不是最优解。只动嘴会给考官留下“可能没真写过”的印象。写的过程中还可以边写边讲，把 defineProperty 或 Proxy 的关键参数解释一遍，这种复合输出方式是最加分的。

第四个翻车点在自我介绍时过度强调工具数量和框架版本，忽略业务成果。面试官问你“最近做过什么项目”，如果你只答“用了 Vue3 + Vite + Pinia”，相当于没答。要说清楚项目解决什么问题、你负责哪些模块、有没有性能优化或组件复用上的亮点。

5.3 追问不是背锅，是加分的窗口

很多候选人最怕的是面试官追问。被追问一两轮就开始慌，觉得自己是不是答错了。其实 Vue 面试题里，追问就是“看看你到底知道多深”的探针，答不上来很正常，但不要立刻保持沉默。

举个例子。面试官问“ computed 能监听异步数据吗”，你答“里面发请求不太合适，因为它需要同步返回”。面试官追问“那我想在依赖变化后做请求，该用 watch 还是 watchEffect”。如果你能用“watch 适合指定监听某个源，watchEffect 适合自动追踪副作用中所有依赖”来回应，现场氛围一下子就活了。

如果真不会，也有不太丢分的接法：“这一层原理我没有深入阅读过源码，但根据我的使用经验，我猜它是通过 XX 机制处理的。我可以回去确认后再补上。”这种坦诚 + 推理的表达，通常比硬拗出一个错误答案好太多。在面试官视角里，知道自己不知道，并且能给出合理的获取信息路径，本身就是一个合格工程师的素质。

5.4 手写题无法回避的几个基础模板

试卷型 Vue 面试题里，手写题出现的概率很高。这里整理几个我建议你必须练到形成肌肉记忆的基础模板，面试现场不用想语法，直接能落笔。

第一个是手写一个简易响应式系统。基于 Vue3 的 Proxy，维护一个 targetMap，get 里收集依赖，set 里触发依赖。如果要求 Vue2 版本，则用 Object.defineProperty 对对象的每个属性做拦截，同时准备一个 dep 数组。这段代码不算长，但能写完整的人其实不多。

第二个是手写一个事件发布订阅。这也是很多框架底层技术，Vue 的事件总线、埋点 SDK、跨组件通信都依赖这个模式。on 方法收集回调，emit 方法遍历执行，off 方法移除。如果你能把 this 绑定、只监听一次 once 也写出来，就非常加分了。

第三个是封装一个异步组件或者动态 import 的懒加载组件。这个更偏工程场景，但面试官可能会让你直接写一个高阶组件，展示加载中 fallback 的处理。把 Suspense 和 defineAsyncComponent 结合起来写，基本就是标准和完美的答案。

第四个是手写一个简单的 v-model 自定义组件，尤其是自定义 checkbox 或者下拉多选这类需要事件回写的组件。这道题手写完，组件通信和事件机制大体也能顺藤摸瓜讲清楚。

这些题目不见得每场都会遇到，但每练一次，你对 Vue 响应式原理、组件机制、渲染流程的理解都会更扎实。准备的深度就是在这些“没有标准答案”的手写练习里拉开的。

6. 关于 Vue 面试备战的一些个人体会

准备 Vue 面试题这几年，我最大的体会是：真正决定面试结果的不只是你会多少 API，而是你能不能把答案讲成一个有逻辑、有细节、有场景的完整故事。面试官和你无冤无仇，他问你刁钻问题不是为难你，而是想确认“招进来之后能不能马上投入生产”。

我个人不太建议按“题目大全”的方式去刷 Vue 面试题。更好的做法是把项目里踩过的坑回顾一遍：你改过 Vue2 的什么大数据渲染性能问题？你在 Vue3 里用过什么 API 解决了组件复用难题？你的状态管理在多人协作时是怎么定的约束？把每个知识点挂到一个真实的项目记忆上，面试时哪怕忘了细节，也能靠上下文推导出合理的表达。

还有一个建议是找朋友做一次模拟面试。Vue 面试题光是“看”和“背”很容易产生错觉，觉得自己全都懂了。模拟面试会让你发现自己张嘴讲时逻辑跟不上，或者代码写不出来。提前暴露这些问题，总好过在真正面试的时候翻车。

最后想说，框架更新迭代很快，但底层的东西从来不骗人。把响应式、组件化、虚拟 DOM、状态管理、性能边界这些基本功吃透，不管面试官出什么花样，你都能接得住。希望这篇梳理能帮你少走一些弯路。祝所有在准备 Vue 面试的朋友，早日拿到满意的 offer。