如果我理解正确的话，JavaScript 中的每个对象都继承自 Object 原型，这意味着 JavaScript 中的每个对象都可以通过其原型链访问 hasOwnProperty 函数。
在阅读RequireJS的源代码时，我偶然发现了这个函数：
function hasProp(obj, prop) {
return hasOwn.call(obj, prop);
}
hasOwn是对 的引用Object.prototype.hasOwnProperty。将此函数编写为
function hasProp(obj, prop) {
return obj.hasOwnProperty(prop);
}
既然我们在这里，我们为什么要定义这个函数呢？这只是为了（轻微）性能提升而对属性访问进行快捷方式和本地缓存的问题，还是我错过了任何可能在没有此方法的对象上使用 hasOwnProperty 的情况？
[我的例子之间]有什么实际区别吗？
用户可能有一个使用 创建的 JavaScript 对象Object.create(null)，该对象将有一个null [[Prototype]]链，因此在其上不可hasOwnProperty()用。由于这个原因，使用您的第二种形式将无法正常工作。
它也是一个更安全的参考Object.prototype.hasOwnProperty()（也更短）。
你可以想象有人可能做过...
var someObject = {
hasOwnProperty: function(lol) {
return true;
}
};
如果hasProp(someObject)像您的第二个示例那样实现它会失败（它会直接在对象上找到该方法并调用该方法，而不是委托给Object.prototype.hasOwnProperty）。
但不太可能有人会覆盖Object.prototype.hasOwnProperty参考。
既然我们在这里，我们为什么要定义这个函数呢？
往上看。
是否只是为了（轻微）性能提升而对属性访问进行快捷方式和本地缓存的问题......
理论上它可能会更快，因为[[Prototype]]不必遵循链条，但我怀疑这可以忽略不计，而不是实现的原因是它的原因。
...还是我错过了
hasOwnProperty可能用于没有此方法的对象的任何情况？
hasOwnProperty()存在于 上Object.prototype，但可以被覆盖。每个原生 JavaScript 对象（但宿主对象不保证遵循这一点，请参阅 RobG 的深入解释）Object.prototype之前在链上的最后一个对象null（当然返回的对象除外Object.create(null)）。
如果我理解正确的话，JavaScript 中的每个对象都继承自 Object 原型
这可能看起来像分裂头发，但JavaScript（ECMAScript 实现的通用术语）和ECMAScript（用于 JavaScript 实现的语言）之间是有区别的。定义继承方案的是 ECMAScript，而不是 JavaScript，因此只有原生 ECMAScript 对象需要实现该继承方案。
一个正在运行的 JavaScript 程序至少由内置的 ECMAScript 对象（对象、函数、数字等）和可能的一些本地对象（例如函数）组成。它也可能有一些宿主对象（例如浏览器中的 DOM 对象，或其他宿主环境中的其他对象）。
虽然内置对象和本机对象必须实现 ECMA-262 中定义的继承方案，但宿主对象不需要。因此，并非 JavaScript 环境中的所有对象都必须继承自Object.prototype。例如，在 Internet Explorer 中实现为ActiveX对象的主机对象如果被视为本机对象将引发错误（因此为什么使用 try..catch来初始化 Microsoft XMLHttpRequest对象）。某些 DOM 对象（如 Internet Explorer 中的怪癖模式中的 NodeLists）如果传递给 Array 方法将引发错误，Internet Explorer 8 及更低版本中的 DOM 对象没有类似 ECMAScript 的继承方案，等等。
因此，不应假定 JavaScript 环境中的所有对象都继承自 Object.prototype。
这意味着 JavaScript 中的每个对象都可以通过其原型链访问 hasOwnProperty 函数
至少对于处于怪异模式（以及 Internet Explorer 8 及更低版本）的 Internet Explorer 中的某些主机对象而言，这不是真的。
鉴于上述情况，值得思考为什么一个对象可能有自己的hasOwnProperty方法，以及调用其他一些hasOwnProperty方法而不首先测试是否是个好主意的可取性。
我怀疑使用的原因Object.prototype.hasOwnProperty.call是在某些浏览器中，宿主对象没有hasOwnProperty方法，使用call和内置方法是一种替代方法。但是，由于上述原因，通常这样做似乎不是一个好主意。
在涉及宿主对象的情况下，in运算符通常可用于测试属性，例如
var o = document.getElementsByTagName('foo');
// false in most browsers, throws an error in Internet Explorer 6, and probably 7 and 8
o.hasOwnProperty('bar');
// false in all browsers
('bar' in o);
// false (in all browsers? Do some throw errors?)
Object.prototype.hasOwnProperty.call(o, 'bar');
另一种选择（在Internet Explorer 6和其他版本中测试）：
function ownProp(o, prop) {
if ('hasOwnProperty' in o) {
return o.hasOwnProperty(prop);
} else {
return Object.prototype.hasOwnProperty.call(o, prop);
}
}
这样，您只需在对象没有它（继承或其他方式）的地方专门调用内置hasOwnProperty 。
然而，如果一个对象没有hasOwnProperty方法，它可能同样适合使用in运算符，因为该对象可能没有继承方案并且所有属性都在该对象上（尽管这只是一个假设），例如in运算符是测试 DOM 对象对属性的支持的一种常见（并且看似成功）的方法。
JavaScript 不保护属性名称hasOwnProperty
如果存在对象可能具有具有此名称的属性的可能性，则有必要使用外部 hasOwnProperty 来获得正确的结果：
您可以将以下代码片段复制粘贴到浏览器控制台以更好地理解
var foo = {
hasOwnProperty: function() {
return false;
},
bar: 'I belong to foo'
};
总是返回 false
foo.hasOwnProperty('bar'); // false
使用另一个对象的 hasOwnProperty 并将其设置为 foo
({}).hasOwnProperty.call(foo, 'bar'); // true
为此，也可以使用Object原型中的 hasOwnProperty 属性
Object.prototype.hasOwnProperty.call(foo, 'bar'); // true
前两个答案（按日期）中给出的信息都是正确的。但是，使用：
('propertyName' in obj)
被提及几次。应该注意的是，hasOwnProperty只有当属性直接包含在被测试的对象上时，实现才会返回 true。
操作员也将in通过原型链进行检查。
这意味着实例属性在传递到hasOwnPropertywhere 时将返回 true，因为原型属性将返回 false。
使用in运算符实例和原型属性都将返回 true。
除了这里的其他答案，请注意您可以使用新方法Object.hasOwn（大多数浏览器都支持并且很快将在其余浏览器中支持），而不是Object.hasOwnProperty.call因为它允许您编写更简洁和更短的代码。
更多关于Object.hasOwn- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn
它更简单：
let foo = Object.create(null);
if (foo.bar != null) {
console.log('object foo contains bar property in any value and
type, except type undefined and null');
// bar property can exist in object foo or any object of the prototype chain
}