Object.hasOwn 对 null 或 undefined 抛出 TypeError 并非什么 bug,而是设计上故意为之——它就是要严格校验参数类型,让数据问题及早暴露;它不做隐式转换,只接受真实对象。配合 `obj != null && Object.hasOwn(obj, 'key')`
Object.hasOwn 对 null 或 undefined 抛出 TypeError 并非什么 bug,而是设计上故意为之——它就是要严格校验参数类型,让数据问题及早暴露;它不做隐式转换,只接受真实对象。配合 `obj != null && Object.hasOwn(obj, 'key')` 这种写法,就能稳稳地安全使用。

直接说结论:Object.hasOwn 对 null 或 undefined 会直接抛出 TypeError。这并非设计缺陷,而是刻意为之——它只认对象类型,不进行隐式转换。
长期稳定更新的攒劲资源: >>>点此立即查看<<<
与传统的 obj.hasOwnProperty() 不同,Object.hasOwn 是静态方法,不依赖目标对象的原型链或内部结构。但它更为严格——仅对真实对象有效。这种"遇错即报"的机制,有助于尽早发现数据源问题,避免 bug 在深层逻辑中蔓延。
Object.hasOwn(null, 'key') → 直接报 TypeError: Cannot convert undefined or null to objectObject.hasOwn(undefined, 'key') → 同样报错Object.hasOwn({}, 'key')、Object.hasOwn(new Date(), 'getTime') → 正常工作实际开发中,对象可能来自 API 响应、用户输入或可选参数,因此主动防护是必要的:
obj != null && typeof obj === 'object' 前置判断obj != null && Object.hasOwn(obj, 'prop')Object.hasOwn(obj || {}, 'prop') —— 若 obj 为字符串或数字,obj || {} 会掩盖类型错误,且字符串/数字对象可能包含意外的自有属性(如 'abc'.length)这种严格性恰恰是它的优势:
'prop' in obj:对 null/undefined 返回 false,看似安全,但会查询原型链,可能误判继承属性obj.prop !== undefined:可防崩溃,但无法区分"属性不存在"与"属性存在但值为 undefined"Object.prototype.hasOwnProperty.call(obj, 'prop'):对 null/undefined 同样报错,行为一致,但写法繁琐,且依赖 Object.prototype 未被篡改传入 Symbol 时,对象参数也必须有效:
const sym = Symbol('id'); Object.hasOwn({[sym]: 1}, sym)Object.hasOwn(null, sym) → 报错,与字符串键一致Object.hasOwn(obj, 'Symbol(id)') → 不会匹配 Symbol 键,因为字符串与 Symbol 属于不同类型侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述