object.hasown 专用于单属性存在性检查，o(1) 时间复杂度且不访问原型链；reflect.ownkeys 用于获取全部自有键，o(n) 时间复杂度，适用于需完整结构的场景。

Object.hasOwn 和 Reflect.ownKeys 解决的是不同问题，性能对比本身意义不大——它们不是替代关系，而是分工明确的工具。实际影响性能的，是你用错场景，而不是方法本身慢。

Object.hasOwn 的性能特点

它专为单属性检测设计，内部实现高度优化，开销极小：

• 不遍历属性列表，只做一次自有属性哈希查找（V8 等引擎已深度优化）
• 不构造新数组、不访问 Symbol 表、不走原型链，纯 O(1) 时间复杂度
• 比 obj.hasOwnProperty(key) 更快且更稳定——后者需动态查原型链，还可能被覆盖
• 对 Object.create(null) 这类无原型对象也零额外成本

Reflect.ownKeys 的性能特点

它返回完整自有键列表，本质是一次性全量采集，开销取决于对象属性规模：

• 时间复杂度为 O(n)，n 是对象自身属性总数（字符串 + Symbol）
• 比 Object.keys() 略重（因要合并 Symbol 键），但远轻于遍历+过滤组合操作
• 不会访问原型链，但需枚举所有自有属性描述符，包括不可枚举项
• 在深克隆、序列化等需要完整结构的场景中，一次调用比多次 hasOwn 判断更高效

什么时候该关心性能？关键看使用模式

真正影响性能的不是单次调用，而是误用导致的冗余操作：

• 用 Reflect.ownKeys(obj).includes(key) 替代 Object.hasOwn(obj, key) —— 多做了全量枚举，严重浪费
• 在循环中反复调用 Reflect.ownKeys 而不缓存结果 —— 每次都重新采集，属性越多越拖慢
• 用 for...in + hasOwnProperty 组合代替 Object.hasOwn —— 多一层原型判断 + 循环开销
• 对简单存在性检查硬套 Proxy + Reflect.has —— 函数调用和 trap 开销远高于 hasOwn

实用建议：按目标选，不为“快”而牺牲语义

写代码时优先保证逻辑清晰和行为准确，现代 JS 引擎对这两个 API 都有良好优化：

• 查一个属性是不是对象自己的 → 用 Object.hasOwn(obj, key)，又快又准
• 要拿到对象全部自有键（含 Symbol 和不可枚举）→ 用 Reflect.ownKeys(obj)，一次到位
• 需要批量检查多个 key 是否都存在 → 先 Reflect.ownKeys(obj)，转为 Set 再 .has() 查询，比反复调用 hasOwn 更优
• 处理用户输入或配置对象时，别图省事用 in 或 hasOwnProperty，Object.hasOwn 是安全与性能兼顾的默认选择