企业官网建设流程全解析

做前端这几年，Vue 2和Vue 3的响应式对比几乎是绕不过去的题。面试要考，项目迁移要评估，连同事之间聊性能优化，聊到最后也会回到 Object.defineProperty 和 Proxy 这两条技术路线上。简单说，Vue 2靠的是 Object.defineProperty 给对象属性逐一挂上 getter/setter，Vue 3 换成了 Proxy 直接代理整个对象，再配合 Reflect 做转发。两套方案各有取舍，也各自埋了不少坑，这篇内容就把它们掰开揉碎聊清楚。如果你正打算把老项目升级到 Vue 3，或者在新项目里做技术选型，再或者准备面试想把这部分彻底吃透，这篇都很适合读一遍。

1. 从“数据变了视图跟着变”说起：响应式的底层逻辑

1.1 响应式在框架里扮演什么角色

先说清楚响应式系统到底在解决什么问题。

前端开发的核心矛盾之一，是数据和 DOM 之间的同步。传统 jQuery 时代，你改了数据还要手动去操作 DOM，页面一复杂，代码维护成本直接指数级上升。MVVM 框架出现后，“数据到视图”的更新链路被自动化了，Vue 的核心就是这个自动化链路里的数据监听模块。

可以打个比方：Vue 的响应式系统像一栋楼的供水管线。水管里的水是数据，水龙头就是页面里展示数据的组件。你不可能每次想喝水都跑到楼顶看水箱水位，再把水桶拎下来。Vue 帮你铺好了管道，水箱水位一变，水龙头自动流出对应流量的水。响应式要做的，就是当“水箱水位”（响应式数据）发生变化时，自动通知“水龙头”（组件）去更新。

具体拆开看，这套机制包含三个角色：Dep（依赖收集中心，相当于水管调度站）、Watcher（观察者，相当于各家水龙头开关），以及被劫持后的响应式数据（相当于带传感器的水箱）。组件渲染时读取响应式数据，触发 getter，getter 把当前组件对应的 Watcher 收进 Dep；之后数据变化触发 setter，setter 通知 Dep 里的 Watcher 执行更新函数，组件重新渲染。

这个“读取时收集依赖、修改时触发更新”的闭环，就是 Vue 响应式的核心逻辑。不管 Vue 2 还是 Vue 3，底层设计目标是一样的，差别只在于用什么样的 JavaScript 能力去实现这个闭环。

1.2 两个版本的核心技术选型

Vue 2 用来实现闭环的底层 API 是 Object.defineProperty，它可以在对象已有属性上定义 getter 和 setter。Vue 2 初始化 data 时会递归遍历每个属性，给它们逐一加上监听。Vue 3 则换成 ES6 的 Proxy，直接“包”在目标对象外面，统一拦截对对象的读取、赋值、删除、遍历等各种操作。

为什么 Vue 2 不用 Proxy？因为 Vue 2 发布时 Proxy 的浏览器支持度不够，尤其是当时的 IE 生态还没有退出历史舞台。Vue 3 选择 Proxy，换来了更强的拦截能力，代价是彻底放弃对老浏览器的兼容。这不是简单的能力对比，而是一个框架在大版本升级时基于浏览器环境做出的技术路线选择。

这里有个容易产生的误解：好像 Object.defineProperty 已经过时了。其实不是，它在很多场景下依然够用，而且兼容性无敌。只是在做“整个对象的全面监听”时，它天生不如 Proxy 完整。理解了这个前提，后面的优缺点分析就都顺理成章了。

2. Vue 2 的响应式设计：Object.defineProperty 的优点与局限

2.1 Object.defineProperty 的工作机制

Vue 2 对响应式的处理集中在初始化阶段。data 对象传入后，Vue 会创建 Observer 实例，把一个对象整体变成响应式。核心逻辑可以简化理解成这段代码：

function defineReactive(obj, key, val) { // 如果 val 还是对象，继续递归 observe(val) const dep = new Dep() Object.defineProperty(obj, key, { enumerable: true, configurable: true, get() { if (Dep.target) { dep.depend() } return val }, set(newVal) { if (newVal === val) return val = newVal dep.notify() } }) }

每次执行 defineReactive，都会同时创建一个 Dep 实例。注意这里先把 val 做了 observe 递归，也就是说，如果 data 里有一个很深的对象，Vue 2 在初始化时就会立刻递归到底，把每一层的每个属性都加上 getter/setter。这是 Vue 2 初始化性能的天然瓶颈。

getter 里做的事很单纯：判断当前有没有正在渲染的 Watcher，有就把它收集进 Dep。setter 里比较新旧值，变化后调用 notify 触发 Watcher 更新。发布订阅模式原理不难，但胜在稳定，Vue 2 大量业务项目能维持良好表现，这套机制功不可没。

2.2 对象属性的新增删除与 Vue 2 的补救

Object.defineProperty 只能针对已存在的 key 操作，这是它最致命的地方。Vue 2 里，直接给 data 对象新增一个属性，界面不会更新。你只能通过 Vue.set（也就是实例上的 $set）做补救。$set 的实现原理是：新增属性时，手动调用 defineReactive 给这个新 key 也加上 getter/setter，同时触发一次 dep.notify，让依赖重新执行。

删除属性的情况更尴尬。Vue 2 没有真正的“删除监听”，Vue.delete 是直接 delete 属性后手动触发更新。所以业务代码里经常需要这种写法：

this.$set(this.obj, 'newKey', newValue) this.$delete(this.obj, 'delKey')

这种写法的存在，本质上是因为底层拦截能力缺失，算是框架做的补偿机制。实际项目里最常见的坑是：接口返回动态数据，前端把这些字段直接挂到 data 对象上，结果页面怎么都不更新，最后才想起用 $set。这就是响应式设计限制直接造成的业务问题。

2.3 数组的“半响应式”处理

Vue 2 对数组没有用 Object.defineProperty 逐项监听下标，因为如果数组很长，逐个给下标定义 getter/setter 性能开销很大，而且很多场景其实不需要监听每个下标。Vue 2 选择了另一种方案：改写数组原型方法。

在 Observer 构造时，Vue 2 把数组原型的七个会修改自身的方法（push、pop、shift、unshift、splice、sort、reverse）替换成自定义实现。这些自定义方法内部先调用原生方法，再手动触发依赖更新。也就是说，只有这七个方法能触发数组变化。

这里有一个非常容易忽略的细节：直接通过下标赋值item[0] = xx，或者修改数组长度length，都不会触发响应式更新。官方文档也明确提示过这一点。项目里我见过有人以为能 push 就说明数组都响应，结果用下标赋值时页面没反应，排查半天。

所以 Vue 2 在数组上的正确操作姿势是：

• 用 splice 或者 push、pop 这类能拦截的方法处理；
• 或者整条赋值，比如this.items = [...this.items, newItem]；
• 再或者用this.$set(this.items, index, value)替换某个旧下标。

这些特殊约定学习成本不高，但在团队协作时经常被忽略。代码里“非预期不更新”的 bug，大多数都出在这些边界场景里。

3. Vue 3 响应式系统的重构：Proxy/Reflect 的取舍

3.1 Proxy 与 Reflect 配合，拦截的是“对象本身”

Vue 3 用 Proxy 直接包住整个目标对象，所有对这个对象的操作都可能被拦截。它不用关心对象里目前有哪些字段，因为拦截发生在访问动作上，而不是属性定义上。

一个极简示例：

function reactive(target) { return new Proxy(target, { get(target, key, receiver) { const result = Reflect.get(target, key, receiver) track(target, key) return isObject(result) ? reactive(result) : result }, set(target, key, value, receiver) { const result = Reflect.set(target, key, value, receiver) trigger(target, key) return result }, deleteProperty(target, key) { const result = Reflect.deleteProperty(target, key) trigger(target, key) return result } }) }

这里用 Reflect 而不是直接target[key]，原因很微妙。Reflect.get / Reflect.set 可以把 this 指向 receiver，也就是代理对象本身。假设目标对象内部有一个互相引用的方法，如果陷阱里用target[key]直接取值，getter 内部 this 可能指向原始对象，后续属性访问就无法再次被代理拦截，响应式就会断掉。用 Reflect 加 receiver 才能保证整条访问链都在代理的管控范围内。

除了 get、set、deleteProperty，Proxy 还提供 has、ownKeys 等一系列陷阱。Vue 3 利用它们把依赖收集的覆盖面扩大了很多：in操作符、Object.keys这类遍历操作也能被拦截。deleteProperty 陷阱的存在，让删除属性这个动作第一次真正纳入响应式体系。

3.2 懒代理带来的性能优势

前面提过，Vue 2 初始化时递归 observe 了所有属性，深层大对象一旦存在，初始化开销会明显上涨。Vue 3 的 reactive 则是“懒代理”：调用 reactive(target) 时只给最外层包一层 Proxy，内部嵌套的对象只有当你通过 get 真正访问到时，才会在 get 陷阱里把它 reactive 一次并缓存下来。

这个设计相当于把“预先铺好所有管道”改成了“用到哪根通哪根”。大多数业务组件只关心自己用到的状态，很多深层数据根本不会被读取，懒代理直接省掉了这部分初始化成本。所以同样是几万条数据的数组，Vue 2 初始化时可能卡顿明显，Vue 3 首次渲染会更顺滑。

不过这里也有一个性能权衡：Proxy 的 get/set 本身比普通属性访问慢一些。如果应用极端地高频读取深层嵌套对象，理论上 Vue 3 会多一些开销。但实际项目中这种场景不多，而且 Vue 3 还对代理对象做了缓存，同一对象不会重复代理，整体上收益远大于损耗。从多数项目体感来看，Vue 3 在数据规模较大时通常更快，尤其体现在初始化和深层大对象首次渲染阶段。

3.3 新增能力与代理对象带来的限制

Vue 3 支持 Map、Set、WeakMap、WeakSet 这些 ES6 集合类型。这个能力是 Vue 2 完全不具备的。Vue 3 为集合类型准备了专属的处理器，重新包装了 get、set、add、delete、clear 等方法，让集合的读写和迭代操作也能完成依赖收集与更新触发。业务里用 Set 做选中态管理，或者用 Map 缓存数据，都可以直接放进 reactive 里使用。

还有一个容易忽略的变化：reactive 不处理原始类型，只接受对象。原始值要用 ref 包装。ref 的底层本质上是把一个值包装成带 value 属性的对象，通过拦截对 value 的读取和修改来收集依赖和触发更新。所以 Vue 3 里 ref 在模板中会自动解包，在 JavaScript 里必须显式写 .value。

Proxy 做不到的事，是兼容性。Proxy 无法被 polyfill，只能依赖浏览器原生实现，因此 Vue 3 彻底放弃了对 IE 11 及以下的兼容。如果你的项目必须支持老浏览器，Vue 3 这套响应式方案完全用不了。这点在做技术选型时，需要提前跟客户或上级对齐，不要等代码写了一半才发现这个硬约束。

4. 实战对比：同一份业务需求在两个版本里的写法差异

4.1 新增和删除属性的写法变化

以接口返回数据为例，模拟一个更新的用户信息场景：

// Vue 2 this.$set(this.userInfo, 'avatar', response.avatar) this.$delete(this.userInfo, 'oldField') // Vue 3 this.userInfo.avatar = response.avatar delete this.userInfo.oldField

Vue 3 里新增、删除属性，只要操作的是 reactive 对象，这些改动都会立即触发组件更新，不需要再调任何辅助方法。这个写法跟普通 JavaScript 几乎一致，心智负担小了很多，团队新成员上手时，基本不会出现“我明明加了属性怎么页面不动”这种困惑。

不过有一点要提醒：直接delete在部分工程化环境会被 ESLint 限制，或者团队代码风格不喜欢这个操作符。这种情况下可以改用解构重新赋值：

const { oldField, ...rest } = this.userInfo this.userInfo = rest

只要 this.userInfo 本身是 reactive 对象，整体赋值后响应式依然生效。

4.2 数组操作：从绕路到直行

再对比数组需求：

// Vue 2 this.items[0] = 'new' // 无效 this.items.splice(0, 1, 'new') // 有效 this.$set(this.items, 0, 'new') // 有效 // Vue 3 this.items[0] = 'new' // 直接有效 this.items.length = 0 // 直接有效 this.items.push('new') // 有效

在 Vue 3 中，push 触发响应式是因为 push 执行时会对新下标做 set 操作，被 Proxy 拦截；length 变化触发的是数组自有属性的 set，同样会被拦截。所以 Vue 2 里那些 splice、$set 绕路方案，在 Vue 3 中基本不再需要。

但也要注意一个前提：Vue 3 的数组响应式依赖“对 reactive 对象进行操作”。如果把数组从 reactive 对象里取出来，赋值给一个普通变量，再对这个普通变量做操作，响应式就断了。这个和 Vue 2 里把 data 属性提前存到组件外是一样的道理。

4.3 性能和数据规模层面的直观差异

拿一个很大的二维表数据，或者一个后台返回的巨型配置对象来说。Vue 2 初始化时要递归遍历整棵对象树，这个阶段耗时与数据规模成正比。Vue 3 的 reactive 创建本身很快，因为只包一层代理，只有真正渲染到某个字段时，才会把该字段嵌套的对象转成响应式。

我拿模拟表格数据做过一次对比，几千行级别的数据，Vue 2 里初始化组件明显觉得有延迟，Vue 3 首屏渲染体感更轻。当然这不意味着 Vue 3 在所有场景绝对更快。渲染本身还涉及虚拟 DOM、diff 算法等环节，响应式只是其中一环。但就“数据到视图”的监听机制来看，Vue 3 的懒代理确实把初始化阶段不必要的遍历省掉了。

这里再补充一个底层细节：Vue 3 对已经代理过的对象有缓存，用 WeakMap 保存原始对象到代理对象的映射。同一个对象多次调用 reactive 不会重复代理，也避免了对同一目标创建多个代理实例时互相干扰。这个设计在深层对象被反复读取时性能提升非常明显。

5. 迁移路上最常见的与响应式相关的坑

5.1 响应式丢失的解构问题

Vue 3 里 reactive 对象有个典型坑：直接把属性解构出来，会失去响应式。

const state = reactive({ count: 0 }) const count = state.count // 这里的 count 只是普通变量 function onClick() { count++ // state.count 变了，但视图不会更新 }

正确做法是用 toRefs 做转换：

const state = reactive({ count: 0 }) const { count } = toRefs(state) // 之后通过 count.value 读取和修改，保持响应式

在组合式 API 的 setup 里，如果直接 return state 没问题；但如果 return 了解构后的属性，就要特别小心。这个问题在 Vue 3 的 code review 里出现频率非常高。建议团队在 ESLint 规则里加一条配置，禁止直接解构 reactive 对象成员，从工具层面把风险挡在外面。

Vue 2 里也有类似的坑：把 data 中某个对象提前存到组件外的变量里，后续修改这个外部变量，视图自然不动。不过 Vue 3 因为到处都在用解构赋值，这个坑的出现概率比以前高很多。

5.2 常见问题速查表

下面这张表，基本覆盖了迁移和日常开发里跟响应式相关的高频问题，建议直接截图保存。

这张表里的每一种情况，基本都能在我提到的对应章节里找到原理层面的解释，建议先对照原理再按表操作，理解会更深刻。

5.3 响应式调试技巧

排查“数据变了视图没变”的 bug，我有一套还算实用的流程。

先用浏览器开发者工具确认数据本身变没变。如果变了而且视图没更新：

• 在 Vue 2 里，大概率是响应式劫持缺失，检查是不是用下标赋值数组，或者新增了未初始化属性；
• 在 Vue 3 里，则要看数据是否已经不是 reactive 对象了，比如把响应式对象存进了一个普通对象，或者用 structuredClone 创建了副本，原始数据的变更自然无法触发视图更新。

接下来借助 Vue Devtools 看组件树里的当前 state。如果 state 里没有这个属性，说明它从未被 Vue 接管。Vue 3 的 Devtools 还能显示某个响应式对象当前的 raw 与 proxy 形态，方便判断代理层是否丢失。

最后分享一个容易忽略的细节：如果你往 reactive 对象里塞了一个被 Object.freeze 冻结的对象，这个对象的内部属性不会被代理，单独修改 deep 字段不会触发更新。遇到这种问题，看代码往往发现不了，直接检查对象是否被冻结，基本一击即中。

我个人在实际排查中体会最深的，其实不是响应式原理本身，而是“边界情况才是 bug 的主要来源”这个事实。不管 Vue 2 还是 Vue 3，只要代码里出现了对象引用、深层拷贝、解构赋值这些操作，就要多留一份心去检查响应式有没有被无意中断掉。框架做好了自己的事，剩下的很多时候是开发者自己写的代码在跟框架打架。把底层机制理解清楚，比死记所有 API 写法，更能让你在关键时刻快速定位问题。