检测属性存在性应优先选用in操作符或object.hasown()：in轻量且支持原型链与不可枚举属性，object.hasown()最快且防原型污染；避免使用undefined判定和object.keys().includes()等触发读取或构造的伪检测方式。
检测属性是否存在，本身不直接触发读写操作，但不同检测方式会间接影响性能表现——关键在于是否访问属性值、是否遍历结构、是否触发副作用。选错方法可能让一次简单判断变成内存开销或逻辑错误。
in 操作符：轻量但需遍历原型链
它只检查属性名是否存在，不取值、不触发 getter、不访问属性内容，语义上就是“能不能用 obj.key 访问”。引擎对它做了深度优化，执行极快。
- 优点：语法级操作，无函数调用开销；支持不可枚举属性和继承属性；不会因属性值为 undefined 或 null 而误判
- 注意点：原型链越深，查找路径越长；若对象有很长的继承层级（如多次 Object.create），性能衰减会明显
- 适用场景：判断配置兜底、API 方法是否可用（如 'fetch' in window）
Object.hasOwn() 与 hasOwnProperty()：自有属性检测最快路径
两者都只查对象自身内部属性表，不走原型链，平均时间复杂度接近 O(1)。现代引擎（V8、SpiderMonkey）对它们做了内联和快速路径优化，是检测“对象自己有没有这个 key”的首选。
- Object.hasOwn() 更优：静态方法，不怕原型污染，调用简洁，性能略高于 hasOwnProperty()
- hasOwnProperty() 需谨慎：若对象重写了该方法（如 obj.hasOwnProperty = null），直接调用会失败；安全写法是 Object.prototype.hasOwnProperty.call(obj, 'key')
- 二者都不触发 getter，也不依赖属性值——哪怕属性值是 undefined、null、0 或 false，只要存在，就返回 true
避免触发读写的“伪检测”：undefined 判定和 Object.keys().includes()
这些写法表面像在查存在性，实则引入了不必要的读取或构造行为，既慢又危险。
- obj.key !== undefined：先读取 obj.key，可能触发 getter（带来副作用）、访问 null/undefined 报错、且把 key: undefined 误判为“不存在”
- Object.keys(obj).includes('key')：每次调用都生成新数组，遍历全部可枚举自有属性；漏掉不可枚举属性（如 toJSON）、继承属性；高频调用易引发 GC 压力
- 它们都不是“存在性检测”，而是“值获取 + 值比较”，逻辑错位，性能冗余
Reflect.has()：语义等价 in，但更适配元编程
行为与 'key' in obj 完全一致，也是不取值、不触发 getter 的纯存在性检查。区别在于它是函数式调用，天然支持 Proxy 拦截，适合需要统一拦截属性访问的场景（如响应式系统、Mock 工具）。
- 性能与 in 相当，都是引擎级优化；比 in 多一次函数调用开销，但可忽略
- 不推荐仅为了“看起来更函数化”而替换 in；但在使用 Proxy 时，Reflect.has 是唯一能保证行为一致的方案
- 同样覆盖不可枚举属性和原型链，不关心属性值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
