当前位置：首页 > news >正文

拒绝死记硬背！我是如何通过“内存引用图”彻底终结闭包困惑的？

news 2026/6/28 14:35:48

拨开迷雾：一次深入 JavaScript 闭包与内存模型的探索之旅

引言

JavaScript 中的闭包（Closure）是一个老生常谈的话题，但真正能从底层内存机制上将其彻底讲透的人并不多。在很长一段时间里，我对闭包的理解停留在“函数记住其外部变量”的表层概念上。每当遇到复杂的场景（如防抖节流、循环中的异步回调），我往往知其然而不知其所以然。

最近，通过一系列的深度剖析和自我诘问，我终于构建起了一个关于闭包、堆栈内存以及作用域链的清晰心智模型。本文旨在记录我从困惑到顿悟的整个思维演进过程，希望能帮助同样受困于此的开发者找到突破口。

阶段一：最初的误区与纠正——混淆“调用者”与“作用域”

故事始于一个经典的防抖函数实现。我想弄清楚为什么多次触发事件时，timer变量能够被共享。

JavaScript

function debounce(fn, t) { let timer; // 关键：这个变量为什么能被共享？ return function() { if(timer) clearTimeout(timer); timer = setTimeout(fn, t); } } // debounce 函数只执行了一次 const handler = debounce(fn, 500); // 无论 handler 之后被谁调用，被调用多少次 box.addEventListener('mousemove', handler);

我的纠正认知：

我起初错误地将变量共享归因于调用者（this）相同。通过深入分析，我认识到“调用者是谁”与“作用域在哪”是完全独立的两个维度。timer之所以被共享，根本原因在于外部函数debounce(fn, 500)只执行了一次。

它执行这一次，就在堆内存中创建了一个唯一的闭包环境（仓库），随后返回的函数始终持有这个唯一仓库的引用。

下面的流程图展示了初始化阶段和执行阶段的区别：

Code snippet

阶段二：深入内存模型——理解独立的闭包实例

解决了共享的问题后，新的疑问产生了：如果外部函数执行多次，产生的闭包是共享的还是独立的？

JavaScript

function fun() { let timer = 0; function test() { timer++; } return test; } // 两次独立的调用 const aa = fun(); const cc = fun();

深入内存层面的真相：

为了解答这个问题，我引入了堆（Heap）和栈（Stack）的内存模型。我意识到，必须将“函数的定义”和“函数的调用”区分开来。每次函数调用，都是一次全新的内存分配过程。

如下图所示，aa和cc虽然源自同一个工厂函数，但它们在内存中是两条完全平行的线：

Code snippet

const aa = fun()：在堆中创建了一套全新的环境Scope_A和函数test_A。
const cc = fun()：在堆中又创建了另一套完全独立的环境Scope_B和函数test_B。
它们互不干扰，各自维护私有的状态。

阶段三：终极顿悟——“去中心化”的直连模型

在构建了内存模型后，我迎来了最大的思维障碍，也是理解闭包最关键的一步。

核心困惑与突破：

我曾潜意识地认为，子函数要访问父级变量，必须通过父函数的地址作为中介。我担心如果父函数执行完被销毁了，闭包链条会不会断裂。

最终的顿悟在于发现：闭包的连接是“去中心化”的直连，不需要父函数作为“中间商”。

当const aa = fun()执行完毕，外部函数fun的执行上下文（Execution Context）从栈中弹出。虽然fun的作用域通常会被销毁，但因为返回的test函数（即aa）的[[Environment]]指针依然引用着这个词法环境，根据垃圾回收的可达性原则，这个环境必须被保留在堆内存中。

下图清晰地展示了这种错误的依赖关系与真实的直连关系之间的区别：

Code snippet