JavaScript用hasOwn替代in判断方法

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《JavaScript用Object.hasOwn替代in操作符方法》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

Object.hasOwn 更安全精确检查对象自身属性，避免 in 操作符检查原型链的问题。1. in 操作符会检查对象自身及原型链上的属性，可能导致意外结果；2. 传统用法使用 Object.prototype.hasOwnProperty.call 避免原型链干扰，但写法冗长且存在被覆盖风险；3. Object.hasOwn 是静态方法，直接挂载于 Object，语法简洁且更安全；4. 在遍历对象属性时，若仅需处理自身属性，应配合 Object.hasOwn 过滤继承属性；5. Object.hasOwn 不会受对象自身 hasOwnProperty 属性覆盖影响，确保调用安全；6. in 操作符仍适用于需检查属性是否存在于对象或原型链任意位置的场景。

Object.hasOwn 提供了一种更安全、更精确的方式来检查对象是否拥有自己的属性，它避免了 in 操作符会检查原型链的潜在问题，让你的代码意图更明确，也更健壮。

解决方案

在JavaScript中，判断一个对象是否包含某个属性，我们经常会用到 in 操作符。它确实很方便，比如 propertyName in object 就能告诉你这个属性是否存在。但问题来了，in 操作符不仅会检查对象自身的属性，它还会沿着原型链向上查找。这意味着，如果一个属性不在对象本身，但在它的原型链上存在，in 也会返回 true。这在某些场景下可能会导致意想不到的行为，甚至是bug。

举个例子：

const myObject = {
  name: 'Alice'
};
const inheritedObject = Object.create(myObject);
inheritedObject.age = 30;

console.log('name' in inheritedObject); // true (name是继承的)
console.log('age' in inheritedObject);  // true (age是自己的)
console.log('toString' in inheritedObject); // true (toString是Object.prototype上的)

为了解决这个问题，我们通常会使用 Object.prototype.hasOwnProperty.call(object, propertyName)。这个方法只检查对象自身是否拥有某个属性，不考虑原型链。虽然它有效，但写法上总觉得有点冗长，而且 hasOwnProperty 本身也可能被对象上的同名属性覆盖，虽然这种情况不常见，但理论上存在风险。

而 Object.hasOwn 就是为了解决这些痛点而生的。它是一个静态方法，直接挂载在 Object 上，用法简洁明了：Object.hasOwn(object, propertyName)。它和 Object.prototype.hasOwnProperty.call 的行为完全一致，只检查对象自身的属性，但更安全、更易读。

const myObject = {
  name: 'Alice'
};
const inheritedObject = Object.create(myObject);
inheritedObject.age = 30;

console.log(Object.hasOwn(inheritedObject, 'name')); // false (name是继承的，不是自己的)
console.log(Object.hasOwn(inheritedObject, 'age'));  // true (age是自己的)
console.log(Object.hasOwn(inheritedObject, 'toString')); // false (toString是原型链上的)

你看，代码是不是一下子清晰了很多？当你的意图就是“我只想知道这个属性是不是对象自己的”，那么 Object.hasOwn 绝对是首选。它避免了原型链的干扰，让你的逻辑更严谨。

为什么 in 操作符在某些场景下会带来麻烦？

in 操作符的“麻烦”之处，主要源于它对原型链的遍历特性。在很多时候，我们关心的是一个对象“自己”有什么属性，而不是它通过继承“拥有”什么属性。这种混淆，尤其在处理来自外部的、结构不确定的数据时，很容易引发问题。

想象一下，你正在遍历一个对象的属性，比如使用 for...in 循环（虽然现在更推荐 for...of 搭配数组，但 for...in 依然有其用途）。如果不加判断，for...in 会枚举所有可枚举的自身属性以及原型链上的可枚举属性。这可能会导致你处理了本不该处理的属性。

const baseConfig = {
  timeout: 5000,
  logLevel: 'info'
};

const userConfig = Object.create(baseConfig);
userConfig.maxRetries = 3; // 用户自定义的属性

for (const key in userConfig) {
  // 如果不加 hasOwn 判断，这里会输出 timeout 和 logLevel
  // 而我们可能只关心 userConfig 自身设定的属性
  console.log(`Key: ${key}, Value: ${userConfig[key]}`);
}
// 实际输出：
// Key: maxRetries, Value: 3
// Key: timeout, Value: 5000
// Key: logLevel, Value: info

在这种情况下，如果你只想获取 userConfig 对象“自己”定义的属性，那么 in 操作符就显得力不从心了。你不得不额外加上 Object.hasOwn（或 hasOwnProperty）来过滤，就像这样：

for (const key in userConfig) {
  if (Object.hasOwn(userConfig, key)) {
    console.log(`Own Key: ${key}, Value: ${userConfig[key]}`);
  }
}
// 实际输出：
// Own Key: maxRetries, Value: 3

这不仅增加了代码的复杂性，也反映出 in 操作符在判断“自有属性”这个意图上的不足。它更适合判断“属性是否存在于对象或其原型链上”，这和“属性是否属于对象本身”是两个不同的概念。理解这种差异，对于编写健壮和意图明确的代码至关重要。

使用 Object.hasOwn 相比 hasOwnProperty 有哪些优势？

说到 Object.hasOwn，很多人自然会想到它和 Object.prototype.hasOwnProperty 的关系。毕竟，它们的功能看起来几乎一样：都只检查对象自身的属性，不涉及原型链。那么，为什么还要引入 Object.hasOwn 呢？主要原因在于安全性和简洁性。

Object.prototype.hasOwnProperty 是一个方法，它存在于 Object.prototype 上。这意味着，任何对象都可以通过原型链继承并调用它。但问题是，如果一个对象本身就有一个名为 hasOwnProperty 的属性（或者说，它“覆盖”了原型链上的 hasOwnProperty 方法），那么直接调用 object.hasOwnProperty(propertyName) 就会出问题。

看这个例子：

const maliciousObject = {
  data: 'some data',
  hasOwnProperty: 'I am a string, not a function!' // 恶意或意外覆盖
};

// 尝试检查 data 属性
try {
  console.log(maliciousObject.hasOwnProperty('data'));
} catch (e) {
  console.error('Oops, hasOwnProperty is not a function!', e);
  // TypeError: maliciousObject.hasOwnProperty is not a function
}

// 这种写法是为了避免上述问题，但显得冗长
console.log(Object.prototype.hasOwnProperty.call(maliciousObject, 'data')); // true

在上面的例子中，maliciousObject 意外地（或者说，故意地）将 hasOwnProperty 属性设置成了一个字符串，而不是一个函数。当你尝试调用 maliciousObject.hasOwnProperty('data') 时，JavaScript 会尝试执行一个字符串，结果自然是报错。为了规避这种风险，我们不得不使用 Object.prototype.hasOwnProperty.call(maliciousObject, 'data') 这种更安全但更繁琐的写法。

Object.hasOwn 的出现，彻底解决了这个问题。它是一个静态方法，直接挂载在 Object 构造函数上，而不是通过原型链继承。这意味着你不需要担心 hasOwnProperty 方法被覆盖的问题，因为它根本就不依赖于对象自身的 hasOwnProperty 属性。

const maliciousObject = {
  data: 'some data',
  hasOwnProperty: 'I am a string, not a function!'
};

console.log(Object.hasOwn(maliciousObject, 'data')); // true (安全且简洁)
console.log(Object.hasOwn(maliciousObject, 'hasOwnProperty')); // true (它自身确实有这个属性)

不仅如此，Object.hasOwn 的命名也更直观，更符合现代JavaScript的API设计风格。它直接表达了“对象是否拥有自己的属性”这个意图，让代码的阅读者能够一眼看出其目的。在日常开发中，能用更简洁、更安全的方式表达相同的逻辑，何乐而不为呢？

什么时候你可能仍然需要使用 in 操作符？

尽管 Object.hasOwn 在检查自有属性方面表现出色，并且在大多数场景下都是更优的选择，但我们也不能一概而论地完全抛弃 in 操作符。in 操作符有其特定的应用场景，尤其当你确实需要检查一个属性是否存在于对象或其原型链上的任何位置时，它依然是最佳选择。

举个例子，如果你在编写一个库或者框架，需要检查一个对象是否实现了某个接口（即是否包含某个方法），而这个方法可能是在原型链上定义的，那么 in 操作符就显得非常合适。

class Logger {
  log(message) {
    console.log(`[LOG]: ${message}`);
  }
}

class ErrorHandler extends Logger {
  error(message) {
    console.error(`[ERROR]: ${message}`);
  }
}

const myErrorHandler = new ErrorHandler();

// 我想知道 myErrorHandler 是否具备 log 方法，它可能继承自 Logger
console.log('log' in myErrorHandler); // true (log方法在原型链上)
console.log(Object.hasOwn(myErrorHandler, 'log')); // false (log方法不在 myErrorHandler 自身)

// 我想知道 myErrorHandler 是否具备 error 方法
console.log('error' in myErrorHandler); // true (error方法在 myErrorHandler 自身)
console.log(Object.hasOwn(myErrorHandler, 'error')); // true

在这个例子中，如果你想确认 myErrorHandler 实例能否执行 log 操作，那么 in 操作符就能准确地告诉你，即使 log 方法是继承而来的。而 Object.hasOwn 则会告诉你 log 不是它“自己”的属性，这在某些情况下可能不是你想要的答案。

另一个常见场景是与 for...in 循环结合使用，如果你确实希望遍历所有可枚举的（包括继承的）属性，那么 in 操作符自然是其核心构成部分。当然，在大多数现代JavaScript开发中，我们更倾向于使用 Object.keys()、Object.values() 或 Object.entries() 来处理自有属性，或者使用 for...of 循环处理数组或可迭代对象。

所以，关键在于你的意图：

• 如果你想知道一个属性是否直接存在于对象本身，请使用 Object.hasOwn。
• 如果你想知道一个属性是否存在于对象或其原型链上的任何位置，那么 in 操作符就是你的工具。

理解这两种操作符的设计哲学和适用场景，能够帮助你写出更精确、更符合预期的JavaScript代码。它们不是非此即彼的替代品，而是各有侧重、互为补充的存在。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~