栈内存基础：程序运行时内存布局

讲递归之前，我得先带你看看程序在内存里是怎么活着的。你想想看，一个程序跑起来，内存可不是乱糟糟的一团——它被划分成了几个清晰的区域。我当年刚学这块时，总觉得抽象，直到有一次调试一个内存泄漏的bug，才真正体会到这些分区有多重要。

程序运行时，内存大致分成三块：代码区、栈区、堆区。说白了，就是各司其职。

代码区——你的代码编译后变成一堆二进制指令，就躺在这。它是只读的，别想着运行时改代码，那会出大事。

栈区——这才是我们今天的主角。每个函数调用，都会在栈上分配一块空间，叫栈帧。函数返回时，这块空间自动回收。嗯，这里要注意：栈的大小是有限的，递归太深就会栈溢出。

堆区——你new出来的对象、malloc出来的内存，都在堆上。堆需要你手动释放，或者等垃圾回收器来收拾。我在项目中遇到过好几次堆内存泄漏，排查起来真是头疼。

核心要点：栈是自动管理的，堆是手动管理的。递归主要消耗栈空间，所以递归深度太大会撑爆栈。

每次函数调用，JVM（或Python解释器）都会在栈上压入一个栈帧。函数返回时，栈帧弹出。这就是为什么递归能一层层往回走——栈天然支持这种后进先出的行为。

一个栈帧里，主要装着四样东西：

我画了一张图，帮你理解栈帧的结构：

你看这张图，三个栈帧依次压入栈中。factorial(3)在最下面，factorial(1)在最上面。等factorial(1)算完，结果返回给factorial(2)，然后一层层往上返回。这就是递归的底层机制。

局部变量表，说白了就是函数里那些变量的"储物柜"。每个变量占一个槽位，int、float这些基本类型直接存值，对象类型存的是引用地址。

我记得有一次，我在一个递归函数里声明了一个大数组，结果递归深度才几百层就栈溢出了。后来才发现，局部变量表里的大对象占用了太多栈空间。避坑指南：递归函数里尽量别声明大数组或大对象。

def factorial(n):
    # n 存在局部变量表的第0个槽位
    # 这里千万别声明大数组！
    if n <= 1:
        return 1
    return n * factorial(n - 1)

操作数栈是JVM做计算的地方。比如你要算 a + b，先把a压入操作数栈，再把b压入，然后执行加法指令，两个数弹出，结果压回栈顶。

在递归场景下，操作数栈里会暂存中间结果。比如 n * factorial(n-1)，先算factorial(n-1)，结果压栈，再取n，然后做乘法。这就是为什么递归能正确计算——操作数栈保证了运算顺序。

小技巧：调试递归时，可以打印操作数栈的状态。虽然Python里不能直接看，但你可以用日志模拟：print(f"计算 {n} * factorial({n-1})")，这样就能看到递归的展开过程。

动态链接——每个栈帧里都保存了一个指向运行时常量池的引用。说白了，就是告诉程序：这个方法在常量池里对应哪个符号引用。这样JVM才能找到正确的方法去调用。

方法出口——函数执行完后，该回到哪里继续执行？这个地址就存在方法出口里。正常返回时，恢复调用者的程序计数器；异常返回时，找异常处理表。

我曾经遇到过一个诡异的问题：递归函数里用了try-except，结果异常捕获后栈帧没正确弹出，导致后续计算全乱套。排查了半天，发现是方法出口在异常路径上没处理好。嗯，从那以后我写递归时特别注意异常处理。

警告：递归函数中如果抛出异常，一定要确保异常被正确捕获或传播。否则栈帧可能处于不一致状态，导致难以排查的bug。

栈内存这块，说白了就是函数调用的"舞台"。每个函数上场，搭一个栈帧；演完了，拆掉走人。递归就是函数自己反复上场，栈帧一层层叠起来。

理解这些，你就能明白递归为什么能工作，也明白为什么递归太深会栈溢出。下一节我们会用具体的递归函数，一步步分析栈帧的变化过程。