在JavaScript的奇妙世界里我们每天dou在与变量、对象和函数打交道，代码写得行云流水。但你是否曾停下来思考过当你在代码中敲下 let a = 1 或者 let obj = {} 时这些数据到底在计算机的哪个角落安家？为什么有时候修改一个对象会莫名其妙地影响到另一个？为什么页面跑久了会变得卡顿甚至崩溃？

这一切的答案，dou隐藏在JavaScript的内存模型之中。这不仅仅是一个枯燥的理论概念，它是理解代码执行机制、优化性Neng以及规避那些令人头疼的内存泄漏问题的基石。今天我们就来扒开JS引擎的外衣，深入探究“栈”与“堆”这两个核心角色的运作奥秘。

一、 宏观视角：内存的两大阵营

在JavaScript引擎运行代码时它并不会把所有数据杂乱无章地扔在一起。相反，它将内存划分为了两个截然不同的区域：栈内存和堆内存。这就好比我们整理房间，会把常用的书籍放在手边的书架上，而把不常用的杂物箱放在储藏室。

这两个区域各司其职，共同支撑起了JS程序的运行。它们之间的核心差异，主要体现在存储内容和管理方式上。理解了这一点，你就拿到了解开JS执行逻辑的钥匙。

1.1 内存的生命周期

不管是在哪种编程语言中，内存的生命周期大体上是一致的，无外乎三个阶段：

分配内存当你定义变量或创建对象时系统需要划出一块地盘给它。

使用内存在代码中读写这块内存里的数据，进行运算。

释放内存当数据不再需要时把地盘腾出来给后续的数据用。

在C或C++这类底层语言中，开发者需要像管家一样手动操心“释放”这件事，稍有不慎就会出乱子。但在JavaScript这种高级语言里这一步被隐藏了、透明化了——我们有一个自动化的清洁工，也就是大名鼎鼎的垃圾回收机制。不过别以为有了GC就Ke以高枕无忧，了解它的工作原理依然至关重要。

二、 栈内存：高效的自动管理区

登场的是栈。在JS引擎的底层架构中，栈内存扮演着“极速通道”的角色，专为追求极致的执行效率而生。

2.1 栈的结构特性：LIFO

作为一种数据结构，栈是线性的，它严格遵守“后进先出”的原则。想象一下洗碗时叠盘子的过程：Zui后洗好的盘子会被放在Zui上面而下次取盘子时也是先拿走Zui上面的那个。这种特性决定了栈的操作非常简单、迅速，你只Neng操作栈顶元素，无法随机访问中间的数据。

在JS的执行上下文中，栈被用来管理函数的调用。每当一个函数被调用，JS引擎就会创建一个新的执行上下文，并将其压入调用栈。函数执行完毕，这个上下文就会被弹出，控制权交还给上一层。

2.2 栈里存了什么？

在内存模型中，栈主要用于存储各种基本类型的变量。这包括：

Undefined

Null

Boolean

Number

String

Symbol

BigInt

此外栈还保存了对象变量的指针。注意，这里说的是“指针”，而不是对象本身。

2.3 自动分配与释放

栈内存Zui大的优点在于其管理机制非常简单粗暴——自动分配，自动释放。当变量进入其作用域时系统自动在栈顶给它分配空间；当变量离开作用域时系统自动将这块空间弹出销毁。

因为这种机制，栈内存不需要垃圾回收器介入。它的生命周期随着函数调用的结束而终结，访问速度极快。但也正因为这种严格的后进先出和空间限制，栈的空间通常比较小，不适合存放大数据。

三、 堆内存：动态的引用类型存储区

Ru果说栈是井井有条的军营，那么堆就是一个自由散漫的大型仓库。

3.1 堆的结构特性

与栈不同，堆内存中的数据存储没有什么规律可言。它是运行时动态分配的，内存空间不连续。这就导致了堆的存取速度要比栈慢一些，因为你需要通过引用地址在茫茫“数据海”中找到那个对象。

这里需要特别插播一个容易混淆的概念：在计算机科学的数据结构分类中，还有一种叫“堆”的结构，它讲究“堆顶元素为Zui值”。但在JS的内存模型语境下我们讨论的堆是指用于存放对象的内存区域，不要把这两个概念搞混了。

3.2 堆里存了什么？

堆是引用类型的专属领地。当你创建一个对象、数组或者函数时JS引擎会在堆中开辟一块空间来存放实际的数据，然后在栈中存放一个指向这块堆内存的地址。

例如：let obj = { name: "Tom" }。对象 { name: "Tom" } 实际上住在堆里而变量 obj 在栈里它手里握着一把通往堆中那个对象的“钥匙”。

3.3 垃圾回收的管辖地

因为堆内存是动态分配的，大小不固定，系统无法像栈那样简单地通过弹出操作来回收内存。这就需要垃圾回收机制登场了。

GC的核心判断标准是“可达性”。简单来说只要一个对象Neng够被JS的根对象通过引用链追踪到，GC就认为这个对象是“有用的”，不会动它。反之，Ru果某个对象断绝了所有与外界的联系，变成了孤岛，GC就会在适当的时候把它清理掉，释放内存。

四、 栈与堆的交互：复制与引用

理解了栈和堆的区别，hen多代码中的“怪现象”就Neng解释通了。Zui典型的就是值传递与引用传递的区别。

4.1 基本类型的复制

当你把一个基本类型的变量赋值给另一个变量时系统会在栈中开辟一个新的空间，把值复制过去。

let a = 10;
let b = a; // 栈中复制了一份值
b = 20;
console.log; // 10，a不受影响

因为 a 和 b 是两个独立的栈空间，互不干扰。

4.2 引用类型的复制

而当你操作一个对象时情况就变了。

let obj1 = { age: 18 };
let obj2 = obj1; // 栈中复制的是堆内存的地址
obj2.age = 20;
console.log; // 20，obj1也跟着变了

在这个例子中，obj1 和 obj2 在栈中虽然有不同的位置，但它们存放的指针dou指向了堆中同一个对象。修改 obj2 实际上是修改了堆里的数据，所以 obj1 读取时自然也会kan到变化。这就是所谓的“浅拷贝”问题。

五、 闭包：跨越栈与堆的桥梁

说到栈和堆的交互，闭包绝对是一个绕不开的话题，也是面试中的常客。

正常情况下当一个函数执行完毕，它的执行上下文会从栈中弹出，内部的局部变量理应被销毁。但是闭包打破了这一规则。

function outer {
    let secret = "I am a secret"; // 本该随outer执行结束释放
    return function inner {
        console.log; // inner引用了secret
    }
}
let fn = outer; // inner保留了对secret的引用
fn; // 依然Neng访问到 "I am a secret"

在这个例子中，outer 函数执行完后栈帧本该销毁。但是因为返回的 inner 函数还在引用 outer 作用域里的 secret 变量，JS引擎知道这个变量不Neng丢。于是它会把 secret 从栈中转移到堆中，让它继续存活。

这就是闭包的魔力：它让数据突破了函数生命周期的限制，从“自动管理”的栈区，迁移到了“动态管理”的堆区，直到没有任何地方引用它为止。

六、 内存泄漏：不可忽视的性Neng杀手

虽然GChen聪明，但它不是万Neng的。内存泄漏，这个前端性Neng优化的核心痛点，本质上就是打破了堆内存的“可达性”规则——本该被GC清理的对象，因为意外的引用关系始终处于“可达”状态，导致无法释放。

随着时间推移，这些无法回收的垃圾越积越多，Zui终会导致页面卡顿、响应缓慢，甚至浏览器崩溃。在JS中，内存泄漏的诱因多与“不当保留引用”有关。

6.1 常见的泄漏场景

意外的全局变量忘记加 let/const/var，直接给未声明的变量赋值，这个变量会挂载到 window 上，永远不会被回收。

未清理的定时器设置了 setInterval 或 setTimeout，但在组件销毁时没有清除，回调函数里的引用就一直存在。

游离的DOM引用页面删除了一个DOM节点，但JS代码里还保留着对这个节点的引用。

闭包滥用虽然闭包本身不是泄漏，但Ru果闭包一直被外部引用，它所携带的作用域链就无法释放。

七、 ：Zuo内存的主人

理清栈、堆的内存逻辑，不仅仅是为了应付面试，geng是为了写出geng优雅、geng高效的代码。栈给了我们速度和秩序，堆给了我们灵活和空间，而GC则在后台默默守护。

作为开发者，我们需要敬畏这套机制。在享受JS自动内存管理便利的同时也要时刻警惕不当的引用行为。及时清理定时器、移除不必要的监听器、在适当的时候断开引用，这些dou是写出高性Neng、低内存泄漏风险代码的核心前提。

下次当你写出 let obj = {} 时不妨想一想：这个小对象，此刻正安身在堆的哪个角落，而栈里的指针，又是否正稳稳地指向它？理解了这一切，你就真正掌握了JavaScript的底层脉搏。

---