原型链打平是减少原型链查找深度的性能优化思路，核心是避免高频访问时反复向上查找；可行方法包括构造函数中绑定方法、Object.assign预填充、Object.create(null)切断默认链、静态方法替代实例方法。
原型链打平不是标准术语，而是对“减少原型链查找深度”这一性能优化思路的形象说法。它的核心目标很明确：避免高频访问属性或方法时，反复穿越多层 __proto__ 向上查找，尤其在大型继承体系（如多层框架类、UI组件树、状态管理基类）中，这种开销会累积放大。
为什么深层原型链会影响性能
JavaScript 引擎（如 V8）在查找属性时遵循“就近原则”：先查实例自身 → 再查 __proto__ 指向的原型 → 继续向上直到 Object.prototype 或 null。每跳一层，都涉及内存寻址与属性表匹配。若一个组件类继承自 BaseComponent → UIWidget → Renderable → EventTarget → Object（5 层），每次调用 render() 或 emit() 都需最多 5 次查找——在动画帧或事件密集场景下，可观测到微秒级延迟叠加。
真正可行的“打平”手段（非破坏性）
不推荐直接篡改 __proto__ 或强行合并原型对象（易引发污染和调试断裂）。应优先采用以下安全、可维护的方式：
-
将高频访问的方法/属性提前挂载到实例上：在构造函数中显式复制，而非依赖原型链。例如：
function Button() { this.click = this.handleClick.bind(this); /* 避免每次 render 时查原型上的 click handler */ } -
用
Object.assign(this, Parent.prototype)预填充实例自有属性：仅对只读、无状态的工具方法适用（如utils.format()），避免引用类型共享问题。 -
使用
Object.create(null)构建纯净原型起点：当某类无需继承Object.prototype方法（如纯数据容器），可切断默认链，消除最后一跳开销。 -
静态方法替代实例方法调用：对不依赖
this的逻辑（如校验、转换），定义为类静态方法，完全绕过原型查找。
需要警惕的“伪打平”陷阱
有些做法看似扁平，实则引入更大风险：
- 直接赋值
Child.prototype = Parent.prototype：子类修改方法会污染父类，且constructor指向丢失； - 遍历并深拷贝整个父类原型链到子类原型：失去动态更新能力，父类修复 bug 后子类不生效；
- 用
Proxy拦截get并缓存查找路径：增加代理开销，且缓存失效逻辑复杂，得不偿失。
验证是否值得优化
不要凭直觉优化。先用 Chrome DevTools 的 Performance 面板录制典型操作（如组件批量渲染），查看 GetProperty 或 GetPrototypeProperty 是否频繁出现在火焰图顶部。再用 console.timeStamp() 对比关键方法调用前后耗时。只有当原型查找占比 >15% 且可复现时，才考虑上述手段。
