Object.prototype.hasOwnProperty.call 和 {}.hasOwnProperty.call 之间的区别。（eslint rule guard-for-in）答案

【问题标题】：Difference between Object.prototype.hasOwnProperty.call and {}.hasOwnProperty.call.(eslint rule guard-for-in)Object.prototype.hasOwnProperty.call 和 {}.hasOwnProperty.call 之间的区别。（eslint rule guard-for-in）
【发布时间】：2017-09-02 06:36:06
【问题描述】：

在 eslint 规则 guard-for-in 中，直接使用 for in 是不正确的。好的做法是

for (key in foo) {
    if (Object.prototype.hasOwnProperty.call(foo, key)) {
        doSomething(key);
    }
    if ({}.hasOwnProperty.call(foo, key)) {
        doSomething(key);
    }
}

我的问题是Object.prototype.hasOwnProperty.call(foo, key) 和{}.hasOwnProperty.call(foo, key) 何时会导致不同的结果？任何人都可以举一个具体的例子吗？

【问题讨论】：

标签： javascript eslint

【解决方案1】：

它们永远不会¹导致不同的结果，这就是为什么它们都被认为是正确的。

对象{} 总是继承自对象原型并且没有自己的键，因此访问它上面的.hasOwnProperty 方法会得到你想要的。而Object.prototype 是全局Object 构造函数的不可写属性，所以它也总是引用对象原型。

现在，在某些情况下，表达式并没有按照您的意愿执行：

确实有人覆盖了全局 Object 变量
有人确实在您的范围内隐藏了 Object 标识符，因此它不引用全局
确实有人用其他东西覆盖了Object.prototype.hasOwnProperty
确实有人用其他东西覆盖了Function.prototype.call

_{1：显然，前两个边缘情况只会与Object.prototype 引用混淆，但它们仍然足够前卫，可以忽略不计。}

【讨论】：

我认为它们应该是相同的，但是为什么 eslint 会给出这样的良好实践示例呢？你能解释一下为什么吗？毕竟，你列出的四个案例太前卫了，不值得考虑。
你问他们什么时候给foo.hasOwnProperty(key) 不同的结果？
它们都是可接受的“良好实践”模式。一种更好理解但更容易混淆，另一种更短但更难阅读。