原型链查找不报错但显著拖慢属性访问速度，尤其在高频深层场景下；链越深越慢，线性遍历导致延迟累积、内联缓存失效、调试困难及隐性成本（如json序列化丢失、instanceof失效、内存增高、for...in变慢）；优化应聚焦控制查找行为，优先组合代替继承、缓存高频属性、用object.create(null)、避免运行时改原型。
原型链查找本身不报错，但会实实在在拖慢属性访问速度——尤其在高频、深层场景下。它不是“不能用”，而是“查得越深、越慢”。真正影响执行效率的，不只是单次查找耗时，更在于隐性开销叠加后对运行时稳定性和可维护性的侵蚀。
线性遍历带来可累积的延迟
每次读取 obj.prop，引擎必须从实例自身开始，逐层检查 __proto__，直到找到属性或抵达 null。这个过程无法跳过、无法哈希加速，每层都需一次内存指针解引用 + 对象内部属性表查询：
- 链长翻倍，路径长度基本也翻倍
- 10 层继承链下，普通属性访问比自有属性慢约 3–5 倍（V8 11.5 实测）
- 方法调用经 JIT 编译后差距缩小，但未优化的 getter 或动态计算属性仍很敏感
- 在 requestAnimationFrame、事件处理器或长循环中反复访问第 7 层才定义的属性，延迟会明显累积
内联缓存失效加剧性能波动
V8 的内联缓存（IC）依赖原型链结构稳定。一旦链变深或运行时被修改，缓存容易退化到慢路径：
- IC 缓存键基于“当前对象的隐式原型链结构”，链一变动即失效
- 频繁修改 Parent.prototype（如动态增删方法）会让优化回退
- 中间类若非 final 语义（可被进一步继承），引擎难以做激进优化
- 开发者工具中 console.log(obj) 常折叠原型，调试时难定位属性真实来源
隐性成本常比执行时间更致命
深层原型链带来的不只是“慢”，还有多个不易察觉但影响深远的问题：
- JSON.stringify(obj) 只序列化自有属性，原型上的方法、配置或状态全部丢失
- 跨 iframe 或不同 Realm 的对象，因构造函数原型不等，instanceof 可能意外返回 false
- 每层 Object.create(parent) 都新建一个对象，冗余 prototype 推高内存并拖慢 GC
- for...in 会遍历整个原型链上的可枚举属性，导致数组遍历时意外变慢（实测比 for...of 慢几十倍）
高效应对的关键不是“缩短层数”，而是控制查找行为
优化重点不在纠结“5 层还是 7 层”，而在于让高频路径尽可能短、稳定、可预测：
- 优先用组合代替继承：把复用逻辑封装成独立对象（如 this.formatter = new DateFormatter()）
- 对高频访问的原型属性，在构造函数中缓存引用（如 this._render = this.render.bind(this) 或 this._data = this.data）
- 纯字典或配置场景，用 Object.create(null) 彻底去掉原型链
- 避免运行时改原型；需要动态行为时，优先考虑 Map 或 WeakMap 存储状态
- 用 Chrome DevTools Performance 面板观察 GetPropertyFromPrototype 占比，仅当持续高于 5% 时再针对性调整
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
