JS对象属性变化监听全解析

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个文章开发实战，手把手教大家学习《JS监听对象属性变化方法详解》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

监听JavaScript对象属性变化的核心方法是Proxy和Object.defineProperty；2. Proxy是现代首选方案，能拦截属性的读取、设置、删除及数组方法等几乎所有操作；3. Object.defineProperty仅能监听已存在的属性，无法监听新增属性或数组变异方法，适用于属性固定的简单场景；4. Proxy通过get和set拦截实现深度监听时需递归代理嵌套对象，但存在性能开销、循环引用、对象身份变化、序列化等问题；5. 数组监听在Proxy中天然支持push、pop等方法，因其内部操作会触发set拦截，而Object.defineProperty需hack式重写数组方法；6. 实际开发中推荐新项目使用Proxy实现响应式，老项目或兼容性要求下可沿用Object.defineProperty，但应清楚其局限性；7. 构建复杂响应式系统时建议使用Vue 3等成熟框架，避免重复造轮子。

在JavaScript中，监听对象属性的变化是实现数据响应式、调试或进行数据同步的关键技术。核心方法主要围绕着Proxy和Object.defineProperty展开，它们提供了不同粒度与灵活性的监听能力。现代开发中，Proxy无疑是更推荐的选择，因为它能提供更全面的拦截能力，包括属性的读取、设置、删除，甚至是数组方法的调用等。

解决方案

要监听JavaScript对象属性的变化，最强大且灵活的工具是Proxy。它允许你创建一个对象的代理，并拦截对该对象执行的各种操作，如属性的读取（get）、设置（set）、删除（deleteProperty）等。

举个例子，如果你想在每次数据更新时都做点什么：

const data = {
    name: '张三',
    age: 30,
    address: {
        city: '北京',
        street: '长安街'
    },
    hobbies: ['coding', 'reading']
};

const handler = {
    set(target, key, value, receiver) {
        console.log(`属性 '${String(key)}' 从 '${target[key]}' 变为 '${value}'`);
        // 确保原始操作得以执行，否则属性不会真正更新
        return Reflect.set(target, key, value, receiver);
    },
    get(target, key, receiver) {
        console.log(`访问了属性 '${String(key)}'`);
        return Reflect.get(target, key, receiver);
    },
    deleteProperty(target, key) {
        console.log(`删除了属性 '${String(key)}'`);
        return Reflect.deleteProperty(target, key);
    }
};

const reactiveData = new Proxy(data, handler);

// 测试
reactiveData.age = 31; // 会触发set拦截
reactiveData.name = '李四'; // 会触发set拦截
console.log(reactiveData.age); // 会触发get拦截

// 注意：直接修改嵌套对象属性不会触发顶层Proxy的set，因为address本身没有被重新赋值
// reactiveData.address.city = '上海'; // 不会触发顶层Proxy的set，但可以被get捕捉到对address的访问

// 删除属性
delete reactiveData.age; // 会触发deleteProperty拦截
console.log(reactiveData);

Proxy的强大之处在于它能拦截几乎所有对目标对象的操作，包括对不存在属性的访问或设置，以及数组的各种修改方法（如push、pop等，这些操作最终也会触发内部的set）。

当然，在Proxy出现之前，Object.defineProperty是主要的手段。它允许你为对象的特定属性定义getter和setter。

function defineReactive(obj, key, val) {
    Object.defineProperty(obj, key, {
        enumerable: true,
        configurable: true,
        get() {
            console.log(`访问了属性 '${key}'`);
            return val;
        },
        set(newVal) {
            if (newVal === val) return;
            console.log(`属性 '${key}' 从 '${val}' 变为 '${newVal}'`);
            val = newVal;
        }
    });
}

const oldSchoolData = {
    message: 'Hello World'
};
defineReactive(oldSchoolData, 'message', oldSchoolData.message);

oldSchoolData.message = 'Hello JS'; // 触发set
console.log(oldSchoolData.message); // 触发get

// 缺点：无法监听新增属性，也无法直接监听数组索引的变化
oldSchoolData.newProp = 'something'; // 不会触发任何监听

Object.defineProperty的问题在于它只能监听已经存在的属性，如果后续添加了新属性，需要手动再次调用defineProperty。对于数组，它也无法直接监听push、pop等方法的调用，只能监听通过索引直接赋值的情况。

Proxy 与 Object.defineProperty 究竟如何抉择？

这确实是个老生常谈的问题，但对于实际项目来说，选择哪种方式，其背后的考量远不止“新旧”那么简单。我个人觉得，如果你正在构建一个全新的、需要高度响应式的数据系统（比如一个类Vue 3的框架），或者你需要对对象操作进行全面、细粒度的拦截，那么毫无疑问，Proxy是你的首选。

Proxy的优势在于它的“非侵入性”和“全面性”。它不需要修改原始对象的属性定义，而是像一个守门员一样，在任何操作到达目标对象之前，都能先被它截获。这意味着你可以轻松地监听属性的添加、删除，甚至是方法调用。这对于构建像Vue 3那样的数据响应系统来说至关重要，它避免了Vue 2中Object.defineProperty带来的诸多限制，比如无法直接检测对象属性的添加或删除，以及数组索引的直接修改。

而Object.defineProperty，在我看来，更适合那些你只需要对少数已知属性进行精确控制的场景。比如，你可能想创建一个计算属性，或者在某个特定属性被访问时触发一个副作用。它的粒度更细，但同时也更“笨重”——你需要为每一个你想要监听的属性显式地定义getter和setter。如果对象属性很多，或者属性是动态生成的，这种方式会变得非常冗余且难以维护。历史地看，Vue 2之所以选择它，是因为当时Proxy的浏览器兼容性还不够好，这本身就是技术选型中一个绕不过去的坎。现在，Proxy的兼容性已经相当不错了，所以，除非有特别的兼容性要求（比如IE），否则真的没必要再纠结Object.defineProperty了。

总而言之，新项目无脑选Proxy，老项目或特定场景下，Object.defineProperty依然有其一席之地，但要清楚它的局限性。

监听数组变化，Proxy 有何独到之处？

数组的监听在JavaScript中一直是个有点让人头疼的问题，尤其是在Object.defineProperty的时代。那时，我们都知道直接修改数组长度、或者使用push、pop、splice等方法，Object.defineProperty是无法直接感知的。因为这些操作本质上是数组原型链上的方法调用，而不是直接对某个索引属性进行赋值。Vue 2为了解决这个问题，不得不对数组的原型方法进行“魔改”，也就是所谓的“数组变异方法”，这听起来就有点复杂和hacky。

而Proxy的出现，简直是为数组监听带来了福音。它的“独到之处”在于，它能拦截对目标对象的所有操作，这其中就包括了数组的各种方法。当你在一个Proxy代理的数组上调用push时，这个操作最终会触发Proxy的set拦截器，因为push方法内部会涉及到对新元素的索引赋值，以及对length属性的修改。

举个例子：

const myArray = [1, 2, 3];
const arrayHandler = {
    set(target, key, value, receiver) {
        console.log(`数组元素或属性 '${String(key)}' 发生变化：从 '${target[key]}' 变为 '${value}'`);
        return Reflect.set(target, key, value, receiver);
    },
    deleteProperty(target, key) {
        console.log(`删除了数组元素或属性 '${String(key)}'`);
        return Reflect.deleteProperty(target, key);
    }
};

const reactiveArray = new Proxy(myArray, arrayHandler);

reactiveArray.push(4); // 会触发set拦截器，因为push会改变length属性和新增元素
// 输出：
// 数组元素或属性 '3' 发生变化：从 'undefined' 变为 '4'
// 数组元素或属性 'length' 发生变化：从 '4' 变为 '4' (这里是因为length属性也被修改了)

reactiveArray[0] = 10; // 同样触发set拦截器
// 输出：
// 数组元素或属性 '0' 发生变化：从 '1' 变为 '10'

reactiveArray.pop(); // 也会触发set和deleteProperty拦截器
// 输出：
// 数组元素或属性 'length' 发生变化：从 '4' 变为 '3'
// 删除了数组元素或属性 '3'

console.log(reactiveArray);

可以看到，无论是直接通过索引赋值，还是通过push、pop等方法修改数组，Proxy都能很好地捕捉到这些变化。这大大简化了响应式系统对数组的处理逻辑，让代码更干净，也更符合直觉。这无疑是Proxy在处理复杂数据结构，尤其是数组时，相较于Object.defineProperty的巨大优势。

深度监听复杂对象，有哪些实践中的坑？

深度监听复杂对象，也就是当对象内部嵌套了其他对象或数组时，我们希望无论哪个层级的属性发生变化都能被感知到。这在构建响应式系统时非常常见，但实践起来，确实有一些需要注意的“坑”。

Proxy默认是“浅层”监听的。这意味着，当你代理一个对象时，只有直接对这个对象进行的属性操作会被拦截。如果这个对象内部包含另一个对象，并且你修改了内部对象的属性，那么顶层的Proxy是无法感知的。

const deepData = {
    user: {
        name: 'Alice',
        info: {
            age: 25
        }
    }
};

const deepHandler = {
    set(target, key, value, receiver) {
        console.log(`[Top Level] 属性 '${String(key)}' 变化`);
        return Reflect.set(target, key, value, receiver);
    }
};

const reactiveDeepData = new Proxy(deepData, deepHandler);

reactiveDeepData.user.name = 'Bob'; // 不会触发Top Level的set
// 因为你没有改变 reactiveDeepData.user 这个引用，只是改变了 user 对象内部的属性。

console.log(reactiveDeepData.user.name); // Bob

要实现深度监听，你需要在每次获取到嵌套对象时，都将其也包裹成一个Proxy。这通常意味着在get拦截器中进行递归的Proxy化处理。

function createDeepReactive(obj) {
    if (typeof obj !== 'object' || obj === null) {
        return obj;
    }

    // 避免重复代理
    if (obj.__isProxy__) {
        return obj;
    }

    const handler = {
        get(target, key, receiver) {
            const res = Reflect.get(target, key, receiver);
            // 如果获取到的是对象，且不是Proxy，就递归代理它
            if (typeof res === 'object' && res !== null && !res.__isProxy__) {
                return createDeepReactive(res);
            }
            return res;
        },
        set(target, key, value, receiver) {
            console.log(`[Deep Reactive] 属性 '${String(key)}' 从 '${target[key]}' 变为 '${value}'`);
            return Reflect.set(target, key, value, receiver);
        }
        // ... 其他拦截器如 deleteProperty 等
    };

    const proxy = new Proxy(obj, handler);
    // 标记一下，防止重复代理
    Object.defineProperty(proxy, '__isProxy__', {
        value: true,
        enumerable: false,
        configurable: false
    });
    return proxy;
}

const deepReactiveData = createDeepReactive(deepData);

deepReactiveData.user.name = 'Charlie'; // 会触发set
deepReactiveData.user.info.age = 26; // 也会触发set
deepReactiveData.user.hobbies = ['swimming']; // 新增属性，也会触发set
console.log(deepReactiveData.user.info.age);

实践中的坑：

1. 性能开销： 递归地创建Proxy实例，尤其对于非常庞大或深度嵌套的数据结构，在初始化时可能会带来显著的性能开销。每次访问嵌套属性时，如果它还没被代理，就需要创建一个新的Proxy，这会增加一些运行时负担。
2. 循环引用： 如果对象中存在循环引用（A引用B，B又引用A），递归代理可能会导致无限循环，需要额外的逻辑来检测和处理这种情况，或者设置一个深度限制。
3. 对象身份变化： 每次通过get拦截器返回一个新的Proxy实例，会导致对象身份（===）的变化。这可能会影响到一些依赖对象身份进行比较的逻辑或第三方库。例如，如果你之前缓存了一个原始对象，但现在拿到的是它的Proxy版本，两者就不再全等了。
4. 序列化问题： 默认情况下，JSON.stringify在序列化Proxy对象时，只会序列化其目标对象（target）的属性。如果你的Proxy添加了一些额外的属性或逻辑，这些可能不会被序列化。你可能需要提供一个自定义的toJSON方法或replacer函数来正确处理。
5. this上下文问题： 在Proxy的get拦截器中，如果直接返回目标对象的方法，当这个方法被调用时，其内部的this可能指向Proxy本身而不是原始目标对象。这通常可以通过Reflect.get来解决，它会正确地绑定this。
6. Proxy.revocable的清理： 虽然不常用，但Proxy.revocable可以创建可撤销的代理。这意味着你可以手动解除代理，停止监听。但在实际的响应式系统中，通常不需要手动管理，因为当对象不再被引用时，垃圾回收机制会处理掉。

在我看来，深度监听是响应式框架的基石，但它绝不是一个“开箱即用”的简单特性。它需要仔细权衡性能、内存和开发复杂度。很多时候，框架会采用一些优化策略，比如懒代理（只在需要时才创建嵌套对象的代理），或者通过特定的数据结构设计来避免过度递归。对于我们日常应用开发，如果不是在构建底层框架，直接使用Vue 3或React等框架提供的响应式API会是更明智的选择，它们已经帮你踩过了这些坑。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。