原型链过长虽不报错，但会拖慢属性访问、增加内存开销；v8内联缓存命中率下降，10层链下高频访问比自有属性慢3–5倍，并引发json序列化丢失、instanceof失效、gc压力增大等隐性问题。
原型链过长本身不会导致报错，但会实实在在拖慢属性访问、增加内存开销，并带来一连串隐性问题。真正影响性能的不是“链长”这个数字，而是查找过程的开销和引擎优化失效。
属性访问变慢：线性查找无法跳过中间层
每次读取 obj.prop，引擎必须从 obj 自身开始，一层层检查 __proto__，直到找到或抵达 null。这不是哈希查找，而是逐级指针跳转：
- 每多一层，就多一次对象结构校验和内存解引用
- V8 的内联缓存（IC）对链深度敏感——链越深、越不稳定，缓存命中率越低
- 实测：10 层继承链下，高频访问属性比自有属性慢 3–5 倍（V8 11.5）
隐性成本常被忽略
比“变慢”更麻烦的是这些不易察觉的问题：
- JSON.stringify(obj) 只序列化自有属性，原型上的方法、状态全丢失
- 跨 iframe 或不同 Realm 的对象，instanceof 可能意外返回 false
- 每层 Object.create(parent) 都新建一个对象，若未及时释放，推高内存并拖慢 GC
- 开发者工具中 console.log 常折叠深层原型，调试时难以定位属性来源
实用优化策略
不必追求“绝对扁平”，关键是让高频路径尽可能短、稳定、可预测：
- 优先组合，慎用深层继承：把复用逻辑封装成独立对象（如 this.formatter = new DateFormatter()），通过实例字段持有
- 缓存高频访问的原型方法：在构造函数中写 this.greet = this.greet.bind(this) 或直接赋值 this.greet = Parent.prototype.greet
- 纯字典场景用 Object.create(null)：彻底去掉原型链，避免任何查找开销
- 避免运行时修改原型：V8 的隐藏类优化依赖原型结构稳定，动态增删方法会让优化退化
- 用 Map / WeakMap 替代对象做映射：尤其当键不是字符串或需弱引用时，性能更可控
什么时候真该动手改？
别凭感觉优化。只在满足以下条件时才值得调整原型结构：
- 使用了深度继承（如 A → B → C → D）且频繁调用跨多层的方法
- Chrome DevTools Performance 面板中 GetPropertyFromPrototype 占比持续高于 5%
- 代码中大量使用 for...in + hasOwnProperty 遍历，且实际只需自有属性
