堆在程序运行中的角色
写程序时，变量、对象、数据结构一个接一个地创建。这些内容不会凭空存在，它们得有个地方待着。就像搬家时行李太多，客厅放不下就得找储物间——程序运行时，这个“储物间”就是堆（heap）。
堆是动态分配的主战场
栈负责函数调用过程中的局部变量，空间小但管理高效。而堆不一样，它更大，更灵活，专为那些在编译时不知道大小、或者需要跨函数长期存在的数据准备。比如你写个聊天应用，用户发来一条消息，长度不定，这时候就得往堆上申请一块空间存它。
在 C++ 里，new 一个对象，实际就是在堆上开辟内存：
MyObject* obj = new MyObject();这条语句执行后，obj 指针存在栈上，真正的对象数据却落在堆里。只要你不 delete，这块内存就一直占着，哪怕函数早就执行完了。
堆让复杂数据结构成为可能
数组、链表、树、图……这些结构往往需要动态扩容。比如 ArrayList 在 Java 中能自动增长，背后就是不断在堆上申请更大的数组，把旧数据拷贝过去。如果没有堆，这种灵活性根本实现不了。
再比如游戏加载地图，场景资源动辄几十兆，不可能塞进栈。只能通过堆一步步加载纹理、模型、音效，按需分配，用完释放。
堆也带来麻烦
自由意味着责任。堆上的内存得程序员自己管（或靠语言的垃圾回收机制）。忘了释放，内存越积越多，程序变慢甚至崩溃。这就是常说的内存泄漏。
比如这段 C 代码：
int* data = (int*)malloc(1000 * sizeof(int));
data[0] = 42;
// 忘了 free(data)
每次调用都偷偷吃掉 4KB 内存，跑久了系统就卡了。就像租了仓库堆满货却不续费也不清空，最后仓库爆仓。
现代语言怎么应对
Java、Go、Python 这些语言引入了垃圾回收（GC），自动清理不再使用的堆内存。开发者轻松了，但代价是运行时可能突然“卡一下”——GC 在后台扫描、标记、回收，占用 CPU 时间。
Rust 则换了个思路，用所有权机制在编译期就确定内存生命周期，既不用手动管理，也避免了运行时 GC 的开销。堆还在，但使用方式更安全。
堆不是无限的
物理内存有限，堆再大也有尽头。程序启动时，操作系统给它划一块堆空间。疯狂 new 或 malloc，迟早会触发“内存不足”。这时候要么程序崩溃，要么操作系统介入，杀进程保系统。
线上服务特别怕这个。一个接口被恶意调用，每请求都分配大对象，堆瞬间撑爆，服务挂掉，变成一次简单的拒绝服务攻击。
堆就像程序的后勤中心，不显眼，但一出问题立马瘫痪。理解它怎么工作，才能写出稳定、高效的软件。