作用域链变量查找按“当前作用域→外层函数作用域→全局作用域”顺序线性搜索，逐层匹配；越靠后的层级查找越慢，因需更多比较、缓存命中率低，且全局变量还受属性动态性与内存布局拖累。
作用域链的搜索过程本身不消耗毫秒级时间，但频繁、深层的标识符查找会在大量循环或高频调用中累积成可观的性能开销——尤其在旧引擎或低端设备上，这种开销可能达到0.1~0.5ms/次，积少成多就会影响帧率和响应延迟。
作用域链怎么查变量？从快到慢有明确顺序
每次访问变量（比如读取 a 或给 count++ 赋值），JS 引擎都得按固定路径一层层找：
- 先查当前函数的活动对象（含参数、let/const/var 声明的局部变量）——最快
- 没找到，就查外层函数的作用域（如果存在闭包）——稍慢
- 再没找到，继续往上，直到全局对象（window 或 globalThis）——最慢
这个“一层层找”就是线性搜索，不是哈希查找。位置越靠后，平均比较次数越多，CPU 缓存命中率也越低。
为什么全局变量访问慢？不只是“远”，还牵扯内存布局
全局变量始终挂在作用域链末端，但关键不止是距离：
- 全局对象体积大、属性多，V8 等引擎对它的属性访问常绕过快速路径，走更通用（也更慢）的查找逻辑
- 全局变量易被动态修改（如通过 eval 或 with），引擎不敢做激进优化，比如内联缓存（IC）失效更频繁
- 多个函数共用同一个全局变量时，引擎需额外做写屏障和垃圾回收跟踪，间接拖慢读取路径
哪些写法会放大搜索代价？真实影响场景
以下看似无害的写法，在循环体或动画帧中反复执行时，容易暴露作用域链瓶颈：
- 在 for 循环里反复读写全局计数器：比如 for (let i = 0; i 中 total 是全局变量 → 每次加法都要走完整作用域链
- 闭包嵌套过深且频繁访问外层变量：4 层以上嵌套函数中读取第 3 层声明的变量，搜索要跳过多个活动对象
- 用字符串拼接触发 with / eval：哪怕只出现一次，也会让整个函数的作用域链降级为“不可预测模式”，所有标识符查找退化为兜底慢路径
怎么验证和优化？三步见效
不用猜，用浏览器开发者工具就能定位：
- 打开 Performance 面板，录制一段高频操作（如滚动、动画），看 JS Call Stack 中是否有大量 GetProperty / SetProperty 占比异常高
- 把疑似慢的变量提前缓存到局部作用域：const len = arr.length; 而不是循环里每次都写 arr.length
- 用 let 替代隐式全局（漏写 var/let/const）；对跨函数共享的数据，考虑用模块级常量或显式传参代替全局引用
不复杂但容易忽略
