闭包变量访问快且确定，走静态作用域链；原型属性访问慢且动态，走[[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加属性）
