JavaScript对象属性访问效率取决于原型链长度，链越深、访问越频繁，开销越明显；属性读取比方法更敏感，10层链下慢3–5倍；应优先用组合替代深层继承，并缓存高频访问的原型成员。
JavaScript 对象成员访问的效率，关键不在“能不能找到”，而在于“找多少步才找到”。原型查找本身不是性能瓶颈，但链越深、访问越频繁，开销就越明显——尤其是对属性（非方法）的高频读取。
原型查找是线性过程，无法跳过中间层
每次访问 obj.x 时，引擎严格按顺序执行：
- 先查 obj 自身是否含有 x（自有属性）
- 没有就跳到 obj.__proto__ 上再查
- 还没找到，继续跳到 obj.__proto__.__proto__
- 如此反复，直到抵达 Object.prototype.__proto__ === null
这个过程不支持索引或哈希加速，每一步都是一次内存指针解引用。链长 5 层和 10 层，查找路径长度直接翻倍。
实际开销：属性比方法更敏感
实测数据显示（V8 11.5 + Node.js 19）：
立即学习“Java免费学习笔记（深入）”；
- 10 层继承链下，访问一个原型上的普通属性，比访问自有属性慢约 3–5 倍
- 若该成员是方法，且被 JIT 编译优化过，性能差距会大幅收窄
- 真正拖慢运行的是循环中反复调用 this.update() 这类原型方法，而非单次访问
更值得警惕的是内存与缓存失效
深层原型链带来的隐性成本常被低估：
- 每个中间构造函数的 prototype 都是一个独立对象，占用堆内存
- 大量未使用的 prototype 对象会增加 GC 压力
- V8 的内联缓存（IC）依赖原型链结构稳定；链一变（比如运行时修改 Parent.prototype），缓存容易失效，回退到慢路径
有效缓解策略：不靠猜，靠设计和工具
优化方向应聚焦在工程实践而非微观调优：
- 优先用组合替代深层继承：把可复用逻辑封装成独立对象，通过字段持有（this.formatter = new DateFormatter()）
- 高频访问的原型属性，可在实例初始化时缓存引用（this._render = this.render.bind(this) 或 this._render = super.render）
- 纯数据字典场景，考虑 Object.create(null) 彻底消除原型链
- 用 %DebugPrint(obj)（开启 --allow-natives-syntax）查看对象隐藏类和原型链状态
- 在 Chrome DevTools 控制台输入 obj.__proto__ 逐层展开，验证链是否符合预期
