如果你已经能写出这样的代码：
void foo() {
int x = 42;
}
int* bar() {
int y = 10;
return &y; // 这样写总觉得哪儿怪怪的
}
但脑子里一闭眼，还是想不清楚「这些变量到底住在哪、什么时候会消失」，那这篇文章就是来补这一块“内存地图”的。
很多人第一次听说“栈”和“堆”，是在 C 课上一张 PPT 上：
上半截写着 stack，下半截写着 heap，中间一条虚线，老师顺口补一句：“局部变量在栈上，malloc 在堆上”。
然后下课 bell 一响，这事就仿佛讲完了。
真正写代码的时候，故事才慢慢变得有点戏剧性：
- 有人递归开大数组，一运行就“栈溢出”，进程被系统当场拍死；
- 有人
new得很开心，delete忘得干干净净，线上内存曲线一路向天； - 还有人从函数里偷偷把栈上变量的地址带出去，用得好好的某一天，突然就莫名其妙崩溃。
这些翻车现场背后，其实都在问同一个问题：
程序眼里的“世界版图”是怎样划分的？
谁负责搭建“栈”这个舞台？谁又在暗处经营着那一大片“堆”？
要讲清这件事，很难完全绕开一点历史。
1. 从没有栈、没有堆的年代说起
把时间拨回到还在写汇编的年代，那时候的“内存观”极其朴素：
世界上只有一长条地址线，每个地址就是一间小房子，
你想要什么数据，就自己写死门牌号：
MOV R1, [0x1000] ; 从地址 0x1000 读数据
那时候还没有“栈帧”“堆区”这种高级抽象，
只有一堆寄存器、几条跳转指令，和程序员自己在地址海里游泳。
后来有了编译器，人们开始想：“能不能别让我自己记每一个门牌号了？”
于是局部变量和函数调用这套语法诞生了。
但语法只是表面，底下得有人帮你兜底：
每次调用一个函数，总得有个地方暂存参数、局部变量、返回地址。
于是编译器和硬件一起，设计出了一块专门区域——
“我们留一段内存，从一头开始往下长，
每次进函数就推一块出来，
退函数就原路收回去。”
这就是后来被叫作 调用栈（call stack） 的那一块世界。
“栈”这个词，本来就是个数据结构：先进后出。
只不过有一天，它从教科书里走出来，变成了进程内存布局的一部分。
那“堆”又是哪儿来的呢？
当函数还只是“加减乘除的小帮手”时，编译器完全可以靠栈搞定一切。
直到有一天，程序员开始提出一些麻烦的需求：
- “我不知道要多少个元素，得运行时才知道。”
- “这个对象不能跟着函数一起死，它得活更久。”
- “我想随时增删，结构还挺复杂。”
栈干不了这活，于是人们在内存的另一头，
划出一大片区域给动态分配器管理：
你跟它说“来一块这么大的地”，它给你一个地址；
哪天你不要了，要记得把这块地还回去。
为了和“那个一进一出的调用栈”区分开，
这块区域被很多教材叫成了 heap。中文翻译叫“堆”，
但它和数据结构里的“堆（heap）”几乎没半点关系，
更像是“杂物堆放区”里的那个“堆”字。
到这一步，你可以把脑海里的图先画成这样：
- 有一块“自动摊开又自动收起”的工作台——栈；
- 有一块“你得签合同、自己负责”的长期租赁区——堆。
C 语言做的事情，就是第一次把这两块区域明牌摆到你面前，
并且直言不讳地说：我不会帮你托管太多，自己看着办。
2. 栈：被编译器安排得明明白白
回到你熟悉的 C / C++ 代码世界。
当你写下：
void foo() {
int a = 10;
int b = 20;
}
编译器心里其实已经有一张“栈帧草图”了：
进 foo 的时候，在栈顶摊开一块小区域，把参数、局部变量排个座位表；
出 foo 的时候，把这块区域整体“视为无效”，
等下一次调用新函数的时候，再在上面盖新东西。
你不用写一行内存管理代码，
生命周期就被调用栈这台“隐形机器”稳稳托住了。
这台机器有几个非常“工程味”的特点：
- 快：
分配和回收本质上就是移动栈顶指针，比任何通用分配器都省事。 - 可预测：
谁先进栈、谁后出栈，一目了然；
谁在什么作用域里诞生、哪一行代码之后就失效，编译器都看得清清楚楚。 - 有硬边界：
栈空间不是无限的，一旦你递归太深，或者在栈上搞超大数组，
操作系统会以一种非常直接的方式提醒你：Stack overflow。
从工程视角看，栈上的世界有点像“公司工位”——
每天来上班，桌子上东西齐备；
下班走人，清理干净，第二天可以换个人坐。
很多诡异的 bug，其实只是在违反这条约定。
还拿开头那段代码改一改：
int* bar() {
int y = 10;
return &y;
}
这就好像你把自己工位上抽屉的钥匙，
悄悄塞给隔壁部门的人，让他以后随时来拿东西。
但系统根本不知道你俩之间的“约定”：
等 bar 返回，y 那一坨栈空间就已经被视作“可以重用”；
改天某个函数在同一位置摊开自己的栈帧，原来那点内容就被彻底覆盖掉。
结果就是：
钥匙还在、抽屉早就被换成了别人家的，
你再拿着这把钥匙到处开锁，开出来的全是未知行为。
C++ 把这种情况叫做 悬空指针（dangling pointer）。
听上去玄乎，其实就是栈生命周期被你硬掰弯了。
3. 堆：从 malloc 到 new，以及那些没关上的门
再看另一边的世界。
早期的 C 程序里，动态内存的故事几乎都写成两行：
int* p = malloc(sizeof(int) * n);
/* ... 用 p ... */
free(p);
用一个词概括就是：交易自由，后果自负。
- 分配器只负责给你“地契”和起始地址；
- 至于你在这块地上是盖房子、开仓库还是乱堆垃圾，它不管；
- 你什么时候还地、还不还，它也装作不知道。
C++ 出场时，接过了这套底层机制，但语义上又往前走了一步：
它说：“既然你已经有了构造函数 / 析构函数，那我干脆把**‘申请内存’和‘对象初始化’**绑成一个动作。”
于是有了今天熟悉的 new / delete：
auto p = new int(42); // 内存 + 构造
auto ps = new std::string("hello"); // 同上
delete p; // 析构 + 释放内存
delete ps;
从语言设计角度看，new 比 malloc 多做了几步体面事；
从工程角度看，却又给你多递了几把“没收好的钥匙”：
- 一旦你漏掉
delete，这块内存就挂在进程上不走了，直到进程退出； - 如果你先手滑
delete掉，后面还在用这块内存，就变成另一种版本的悬空指针； - 要是你心大，又
delete了两遍，那就是双重释放，分配器内部的结构都可能被你搞坏。
所谓“内存泄漏大战日志”“线上重启续命”，
本质上就是：太多来自堆上的东西被创建出来，却从来没人负责送它们离场。
后来 C++ 社区反复在这些坑里摔跤，
慢慢悟出了一套今天你已经耳熟能详的口号：
“RAII，一切资源皆对象。
真正要手撸new/delete的地方很少，大部分时候，应该是某个对象在帮你new/delete。”
std::vector、std::string、各种智能指针，其实就是为此诞生的——
它们帮你包住那一块堆内存，
让你用“栈上对象的生命周期”，
去间接管理“堆里的那一大片地”。
4. 当栈遇上堆：一门语言的性格
聊完了“历史渊源”，回过头看 C++ 这门语言，你会发现它的性格其实挺鲜明：
- 一方面，它不舍得砍掉 C 留下来的底层能力：
指针、malloc、裸new，全都还在；
你要贴着硬件跑，它不会拦你。 - 另一方面，它又试图在这片荒地上，
铺一层更安全的道路：RAII、智能指针、容器、引用语义、值语义……
栈和堆就在这里扮演了一个很微妙的角色。
先看栈。
栈上的对象，有一个天然的“值语义气质”：
你在函数里声明一个 std::string，
它就是货真价实的一份字符串状态：
void greet() {
std::string name = "Alice"; // name 的生命周期被函数框住
// ...
}
当你把它按值传给另一个函数时，
语义上就是“再拷贝一份”，
这份拷贝活多久，就让接收方自己决定。
再看堆。
堆上的对象天生具有“共享风险”：
它们不跟着作用域自动死，
必须有人站出来说：“这玩意儿是我负责的，我来决定它什么时候结束生命。”
于是有了各种“谁拥有谁”的表达方式：
- 裸指针：大家都能指过去，谁都可能手滑
delete； std::unique_ptr：同一时刻只有一个主人，想换人可以（move），但不能同时有两个主人（不能 copy）；std::shared_ptr：咱们一起养，看谁先不想要，等最后一个人放手再收场。
如果你把这些工具再和栈联系在一起，会得到一个很有意思的图景：
- 栈：
负责托住“管理者”本身的生命周期。比如一个std::unique_ptr<Foo>在栈上，一旦它出作用域，对应的Foo也在堆里跟着一起消失。 - 堆：
真正容纳那些“大对象、活得久、不好预测数量”的东西，但它不直接暴露给业务逻辑，而是躲在 RAII 对象背后。
于是你得到了一种看上去有点矛盾、实际上又非常 C++ 的搭配：
用栈来管理堆，用值语义来驾驭引用语义。
写着写着，你就会发现，那些年踩过的“栈 vs 堆”的坑，
最后都落在一句话上：
“到底是谁在管生命周期？”
- 返回栈上变量地址？没人负责管那块栈空间了；
new完不delete？没人负责给堆里的那片地退租；- 到处传裸指针？压根没人清楚“谁才是最后那个关灯的人”。
5. 走出栈与堆的小结
如果要用一句略带故事感的话来收个尾，可以是这样：
栈和堆，本来只是编译器和操作系统为了跟你做交易而划出的两块地：
一块承包“短平快”的局部琐事，一块承包“长期复杂”的大工程。
C 把这两块地摊在你面前，C++ 则试图教你怎么在这两块地上当一个负责任的“房东”。
当你再遇到这些熟悉的名词时，不妨这样去看它们：
- 看到一个局部变量，顺手在脑海里标一句：“它只在这一层栈帧里存在。”
- 看到一个
new，立刻追问：“是谁来负责最终的delete？是 RAII 还是某段业务逻辑？” - 看到一个函数签名，不只是看类型，还顺带想一眼：“这里的参数，是在传一个值，还是在递一把可以改原件的钥匙？”
等这些问题变成你的下意识反应，
“栈 vs 堆”就不再是考题上的名词解释，
而是你设计接口、查内存 bug 时，真正会拿出来用的一套世界观。