查找失败比成功更慢，因需遍历整条原型链且无法使用内联缓存（IC）；7层链下缺失访问比自有属性慢4–6倍，IC完全失效。
属性查找失败时的性能损耗比成功查找更严重——因为引擎必须走完整条原型链，且无法利用内联缓存（IC）优化。这不是“找不到就停”，而是强制线性遍历、反复校验、频繁未命中，最终在高频场景中放大为明显延迟。
为什么查找失败特别慢
当你访问 obj.missingProp 时，V8 等引擎会执行以下不可跳过的步骤：
- 检查 obj 自身属性表 → 未命中
- 解引用 obj.__proto__ → 可能触发 CPU cache miss
- 读取该原型的隐藏类，比对 IC 记录 → 失败，降级为慢路径
- 在其属性表中扫描 → 未命中
- 重复以上过程，直到抵达 Object.prototype 或 null
链深每增加一层，就多一次内存跳转和结构校验。实测显示：7 层链下访问缺失属性，比访问自有属性慢 4–6 倍；超过 6 层后，基本退化为纯线性遍历，IC 完全失效。
用工具定位真实损耗点
别靠经验猜，用运行时信号确认问题是否存在：
立即学习“Java免费学习笔记（深入）”；
- 在 Chrome DevTools Performance 面板中录制操作，火焰图里若密集出现 [[Prototype]] 或 LoadIC_Miss 标记，说明大量失败查找正在发生
- 控制台执行 %DebugPrint(obj)，观察 prototype 链长度及是否稳定；若多次执行返回不同隐藏类 ID，说明 IC 因链不稳定而持续失效
- 对比 %timeit obj.existingProp 和 %timeit obj.missingProp —— 后者耗时显著更高（2 倍以上）即为风险信号
高频场景中如何快速识别隐患
这些代码模式最容易暴露查找失败的代价：
- 模板渲染中写 {item.status || 'pending'}，但部分 item 实际没有 status 字段
- 事件处理器里反复调用 this.config?.timeout，而 config 是可选挂载的原型属性
- 使用 for...in 遍历对象且未过滤原型属性，意外触发大量 hasOwnProperty 上溯检查
此时推荐改用 Object.hasOwn(obj, 'prop') 替代 obj.hasOwnProperty('prop')，它不走原型链，能直接拦截失败路径。
降低失败开销的实用做法
核心思路不是避免所有缺失访问，而是让失败更快、更可控：
- 对关键字段做存在性预设：构造函数中初始化 this.status = 'pending'，而非依赖原型默认值
- 用 ?? 或 && 替代可选链前的盲目访问，例如 item?.status ?? 'default' 比 item.status 更安全
- 纯配置对象建议用 Object.create(null) 创建，彻底移除 __proto__，杜绝任何上溯可能
- 在 ESLint 中启用 no-prototype-builtins 规则，防止误用 obj.toString() 这类易触发长链的方法
