闭包变量访问快且确定，走静态作用域链；原型属性访问慢且动态，走[[prototype]]链查找；二者独立无竞争，但设计不当会引发隐性性能陷阱。

当闭包与原型链混用时，性能优先级不取决于“先查哪个”，而取决于访问路径的执行顺序和底层机制差异：闭包变量走作用域链查找，原型属性走 [[Prototype]] 链查找，二者完全独立、互不干扰。实际运行中，谁被访问就走谁的路径，不存在隐式竞争或自动降级。

闭包变量访问：静态作用域决定，快且确定

闭包捕获的是函数定义时的词法环境，变量查找在进入函数执行时即沿作用域链向上遍历，路径固定、无动态代理开销：

• 每次调用闭包内部函数，都直接从已绑定的外层作用域（如 outer 函数的 AO 或词法环境记录）读取变量
• 不涉及属性描述符、可枚举性、hasOwnProperty 判断等运行时检查
• 例如：function outer() { let x = 1; return () => x; } 中的 x 访问几乎等同于局部变量读取，开销极低

原型属性访问：动态委托查找，有链式开销

访问对象属性（如 obj.method）时，JS 引擎按以下顺序进行：

• 先查对象自身属性（own property），命中则返回
• 未命中则通过 [[Prototype]]（即 __proto__）跳转到原型对象，重复该过程
• 每级查找都要验证属性是否存在、是否可访问、是否被屏蔽（如被 Object.defineProperty 设置为不可枚举）
• 链越长、中间原型越复杂（如含 getter/setter、Proxy），耗时越明显

混用场景下的真实性能关系

闭包变量和原型属性不会“抢着被查”，但设计不当会引发隐性性能陷阱：

• 不要在原型方法里反复读取闭包变量：比如把一个高频调用的方法挂到 prototype 上，而它内部又频繁访问外层闭包的 config 对象——此时闭包访问本身快，但方法调用频次高，放大了作用域链遍历总量
• 避免用原型链模拟闭包行为：例如本可用闭包封装私有状态，却改用 this._private + 构造函数初始化，导致每个实例多占内存、且属性访问无法享受闭包的优化路径
• getter 中触发闭包访问需谨慎：若原型上定义了 get value() { return this._cache || compute(this._data); }，而 compute 依赖外部闭包函数，则闭包调用虽快，但 getter 本身的原型链查找+执行开销叠加，可能成为瓶颈

如何判断当前瓶颈在哪

用浏览器 DevTools 的 Performance 面板录制操作，重点关注：

• 调用栈中是否频繁出现 GetProperty / GetPropertyFromPrototype —— 指向原型链查找压力大
• 是否大量 CallFunction 后紧接 ResolveScope —— 表明闭包作用域解析较密集
• 内存堆快照中是否存在大量重复闭包实例（如每个事件处理器都生成新闭包），或原型对象被意外污染（如往 Object.prototype 加属性）