原型链属性查找变慢是因为必须线性遍历每层__proto__，无法跳过中间环节；每层增加指针跳转、隐藏类校验及属性表查询开销，5层以上实测比自有属性慢3–5倍，高频场景下影响显著。

原型链上的属性查找本身不报错，但越深越慢；内联缓存（IC）是引擎用来“记住”查找结果的机制，能大幅提速——前提是对象结构稳定、链路不过深。

原型链查找为什么变慢

每次访问 obj.prop，引擎都得从 obj 自身开始，一层层往上查 __proto__，直到找到或到 null。这个过程是线性遍历，没法跳过中间环节：

• 每层都要做一次内部属性表查询，虽快但非 O(1)
• 每多一层，就多一次指针跳转和隐藏类校验
• 链深超过 5 层后，实测属性访问比自有属性慢 3–5 倍（V8 11.5）
• 高频场景（如动画帧、循环、事件处理器）中，这种开销会被放大

内联缓存怎么帮上忙

IC 不是额外加的缓存服务，而是引擎在执行 obj.prop 这条指令时，就地记下两个关键信息：

• 当时对象的隐藏类（即结构：属性顺序、类型、是否含 getter 等）
• 该属性在该结构下的内存偏移量或访问方式

下次再执行同一行代码，只要对象结构没变，引擎直接按偏移量取值，跳过整个原型链查找——从 O(n) 降为 O(1)。

IC 分三级响应：

• 单态：只见过一种隐藏类 → 硬编码最快
• 多态：见过 2–4 种 → 查小映射表，稍慢但可控
• 超态：类型混杂超阈值（如 10+ 种）→ 放弃缓存，退回慢路径

哪些操作会让 IC 失效或变慢

IC 高度依赖对象结构的稳定性。以下做法会削弱甚至破坏它的效果：

• 运行时动态增删属性（比如 obj.x = 1 后又 delete obj.x）
• 混用不同形状的对象（如 {id: 1}、{_id: 1}、class User 交替传入同一函数）
• 过深或动态修改的原型链（如反复给 Parent.prototype 添加/覆盖方法）
• 频繁使用 in 操作符或 for…in，它们必须完整遍历原型链

实际可落地的优化建议

不必追求极致，但几个简单动作就能避开明显坑：

• 高频访问的原型方法，可在实例初始化时缓存引用：this.sayHi = this.sayHi.bind(this) 或 this.sayHi = Parent.prototype.sayHi
• 纯字典用途对象（如配置项、映射表），优先用 Object.create(null)，彻底切断原型链
• 避免继承链超过 4–5 层；更推荐组合：把复用逻辑抽成独立工具函数或模块，而非层层 extend
• 用 hasOwnProperty 显式区分自有属性，减少不必要的原型链遍历
• 借助 DevTools 的“Performance”面板或 V8 的 %DebugPrint，验证关键路径是否稳定在单态