原型链过深不报错但引发性能雪崩，因每次属性访问强制执行六步底层操作，链深≥7时IC基本失效、全程线性遍历，10层时比自有属性慢3–5倍；高频读取状态、方法、渲染字段最易卡顿。
原型链层级过深不会报错，但会引发性能雪崩——不是因为“层数多”本身，而是每次属性访问都强制执行一整套不可跳过的底层操作，高频调用时延迟快速累积，最终在动画、滚动、渲染等关键路径上表现为肉眼可见的卡顿。
引擎实际在做什么：一次 obj.x 背后的六步开销
V8 并不“往上翻”，而是严格按序执行：
- 查对象自身属性表（基于隐藏类偏移，O(1)但需内存寻址）
- 若未命中，解引用 __proto__ 指针（可能触发 CPU cache miss）
- 读取目标原型的隐藏类结构
- 校验当前内联缓存（IC）是否仍匹配该结构
- 在其属性表中做有序扫描（非哈希查找，是线性遍历）
- 重复以上步骤，直到找到或抵达 null
为什么“深”会雪崩：IC 失效与查找退化
性能断崖出现在特定临界点，而非平滑下降：
- 链深 ≤ 4 层：IC 可稳定复用，访问接近自有属性速度
- 链深 = 5–6 层：IC 开始部分失效，部分调用回退到慢速路径
- 链深 ≥ 7 层：IC 基本失效，引擎放弃预测，全程线性遍历
- 链深 = 10 层：实测比自有属性慢 3–5 倍；万次访问可增加 2–8ms 主线程耗时
真正被拖垮的访问模式
不是所有属性都敏感，以下场景最易触发雪崩：
立即学习“Java免费学习笔记（深入）”；
- this.state、this.isMounted 等每帧都读的状态字段
- 未预绑定的方法调用：this.handleClick()（每次都要找函数）
- 模板中高频读取：item.name、user.role 等渲染字段
- 属性缺失时：obj.missing 会走完整链，IC 更易 miss，放大开销
验证是否真由原型链拖累
不用猜，用工具定位真实瓶颈：
- Chrome DevTools Performance 面板录制滚动，看火焰图中是否密集出现 GetPropertyFromPrototype 或 [[Prototype]] 标记
- 控制台运行 %DebugPrint(obj)，观察 prototype 链长度与 map 是否稳定
- 连续调用 %HasFastProperties(obj)，返回 false 表示已退出快属性模式
- 写轻量测量函数：包裹 10 万次访问，对比 obj.x 与 obj.y（y 在第 8 层原型）耗时差
