C语言递归函数入门：从“求5的阶乘”到调用栈与栈溢出

“求5”这个说法，我猜很多人第一次看到时都跟我一样有点懵：到底要求哪个5？是5的阶乘、5次方、还是1到5的累加？不过放在C语言递归函数这个上下文里，它的指向其实相当明确——绝大多数教材、习题和课程设计里，“求5”指的就是求5的阶乘，也就是5!，即1×2×3×4×5的结果。而这恰恰是递归函数入门时最经典的例题，几乎每个学C语言的人都绕不开它。这篇文章我就从“求5”这个具体问题切入，把递归函数怎么用、为什么用、有哪些坑一次讲透，适合刚接触C语言递归、或者被递归绕晕了想重新理一遍的同学。

1. 先搞明白：“求5”到底在求什么

1.1 同一个“5”，三种不同的出题意图

虽然把“求5”直接理解成“求5的阶乘”最普遍，但不同的教材和习题里，它对“求”的动词定义其实并不统一。常见的“求5”至少有三种含义：

如果你是在做课后习题，我建议你先看题目完整表述，别急着默认是阶乘。但如果你是看到“C语言递归函数解决求5的方法”这种表述，那十有八九指的是“用递归实现5的阶乘”。原因很简单：阶乘的定义本身就是递归的——n! = n × (n-1)!，这个结构刚好和递归函数的“自己调用自己”一一对应，拿出来当例题最顺手。

1.2 递归解决这类问题的天然优势

为什么求阶乘要专门用递归？因为阶乘这个数学定义，本质上就长着一副“递归脸”：

• 5! = 5 × 4!
• 4! = 4 × 3!
• 3! = 3 × 2!
• 2! = 2 × 1!
• 1! = 1

你看，要求5!，先得知道4!；要求4!，先得知道3!……一路套下去，直到一个不再需要继续拆分的基准情况（1! = 1），然后逐层把结果带回来。这种“把一个大问题拆成规模更小的同类型问题，直到小到可以直接解决，再逐层返回”的思路，就是递归。它跟循环不一样的地方在于：循环是用迭代的方式一步步累加，而递归是用函数自身定义的方式不断展开，靠函数调用关系把“拆”和“合”两个阶段天然地表达出来。

2. 递归的核心“为什么”：函数调用栈与递推回归

2.1 调用栈：递归能运转起来的物理基础

很多初学者觉得递归神秘，是因为不清楚函数调用时计算机到底做了什么。C语言里，每次函数调用都会在内存中分配一块区域，叫栈帧，用来存放这个函数的局部变量、参数值、返回地址等信息。递归调用本质上是“同一个函数代码，被多次进入”，每进入一次就压入一个新栈帧，函数返回时就弹出栈帧。这就好比一摞盘子，你一层一层往上放，取的时候只能从最上面一层一层往下拿。

以factorial(5)为例：调用factorial(5)时压入一个栈帧，它里面存着参数n=5；在计算过程中遇到factorial(4)，又会压入第二个栈帧，参数n=4……一直压到factorial(1)。这一路压栈的过程，就是“递推阶段”。等factorial(1)返回1之后，栈帧开始逐个弹出，每一次弹出都向上一层返回一个结果，这就是“回归阶段”。

提示：如果你从来没画过调用栈图，建议拿纸笔把factorial(5)的调用过程画一遍。画完你就能理解为什么递归虽然写起来简单，运行时却并不是“原地算数”，而是在不断开辟新的函数调用空间。

2.2 为什么必须有终止条件：没有终止就是栈溢出

递归函数必须有一个基准情形，也就是终止条件。如果少了它，函数会无限调用自己，栈帧不断压入，直到把内存中的栈空间耗尽，程序崩溃。这种现象就是常说的栈溢出。它不是“死循环”那种CPU空转，而是内存被调用帧塞满后直接爆掉的严重错误。

举一个反面例子，如果写：

int fact(int n) { return n * fact(n - 1); // 永远没有结束条件 }

那么fact(5)会一直调fact(4)、fact(3)、fact(2)、fact(1)、fact(0)、fact(-1)……永远不会有返回的契机。实际运行会得到“段错误”“栈溢出”之类的报错。终止条件就是递归的“闸门”，闸门没装好，程序直接冲出路基。

2.3 递推与回归：并不是所有计算都发生在返回时

递归里有两种计算时机，值得区分。像factorial这种写法：

return n * factorial(n - 1);

乘法发生在回归阶段，因为要先拿到factorial(n-1)的结果，才能乘以n。而如果换成累加写法：

long sum_recursive(int n) { if (n == 1) return 1; return n + sum_recursive(n - 1); }

加法同样发生在回归阶段。但有一些递归写法，比如打印数字的每一位，计算过程会发生在递推阶段——函数先做一件事，再继续调用自己。理解这个区别，能帮你分析“递归到底先做什么、后做什么”，也能避免写出顺序反了导致结果完全不对的代码。

3. 手写C语言递归求5的阶乘：代码、推导与边界

3.1 最简洁的递归阶乘函数

下面这个函数是我在教学中用得最多的版本，短、清晰、够用：

#include <stdio.h> long factorial(int n) { if (n <= 1) // 终止条件：0! 和 1! 都是1 return 1; return n * factorial(n - 1); // 递归步骤：n! = n * (n-1)! } int main() { int n = 5; printf("%d! = %ld\n", n, factorial(n)); return 0; }

运行结果就是：

5! = 120

这里的核心逻辑只有两点：终止条件n <= 1返回1；递归步骤中把n!转化成n乘以(n-1)!。其余所有复杂行为都是C语言函数调用机制自动完成的。代码短不代表它简单，它背后那个调用链才是重点。

3.2 5! 的完整调用过程拆解

把factorial(5)的执行过程一步步展开，是这样的：

factorial(5) -> 5 * factorial(4) -> 4 * factorial(3) -> 3 * factorial(2) -> 2 * factorial(1) -> 1 <- 2 * 1 = 2 <- 3 * 2 = 6 <- 4 * 6 = 24 <- 5 * 24 = 120

箭头向左是递推阶段，箭头向右是回归阶段。你注意看，最底层的factorial(1)返回1之后，每一层往上带的结果分别是1、2、6、24、120——这个数列本身就是中间结果。很多初学者算到一半容易乱，就是因为忘记了“回归阶段从最深一层开始往回算”，而不是从最外层直接算。

3.3 边界条件到底写 n==1 还是 n<=1

不少人习惯写：

if (n == 1) return 1;

这对于“求5的阶乘”这个具体问题没问题，因为你只打算调用factorial(5)、factorial(4)……最终会到达factorial(1)。但如果某天别人用你的函数去求factorial(0)，n==1这个条件就永远不满足，程序会递归到负无穷，最终栈溢出。

从工程角度，写成n <= 1更加健壮。因为数学上0!的定义也是1，所以把0揽进来一起处理完全正确，还能顺带避免边界值引发的崩溃。这个细节很小，但能体现你有没有考虑“函数被调用时参数边界不可控”的情况。

3.4 顺带写写“求5的n次方”的递归版

如果你遇到的“求5”指的是“求5的3次方”之类的幂运算，递归写法逻辑也一样清晰：

double power(double base, int exp) { if (exp == 0) return 1; if (exp > 0) return base * power(base, exp - 1); return 1 / power(base, -exp); // 负指数 }

调用power(5, 3)时，执行链是5 × power(5, 2)，再往下5 × power(5, 1)，再往下5 × power(5, 0)，最终得到125。这里值得注意的额外设计是负指数：把负指数先转成正数递归，最后取倒数。这样一个函数兼顾了正、零、负三种情况，不至于一遇到power(5, -2)就直接出错。

3.5 再写一种：递归求1到5的累加和

如果题意是“求1+2+3+4+5”，递归函数同样信手拈来：

long sum_recursive(int n) { if (n <= 1) return n == 1 ? 1 : 0; return n + sum_recursive(n - 1); }

调用sum_recursive(5)时，执行链是5 + sum_recursive(4)，再4 + sum_recursive(3)……一直加到sum_recursive(1)返回1，整体得到15。这个例子比阶乘简单，但适合用来验证你是否理解了“规模每次减1”的递归结构。

4. 递归 vs 循环：同样的结果，为什么要绕路？

4.1 循环版阶乘与递归版阶乘的对比

求5的阶乘，用循环写非常直观：

long factorial_loop(int n) { long result = 1; for (int i = 2; i <= n; i++) result *= i; return result; }

两版代码都能给出120。那学递归的意义在哪？从“求5!”这个单一任务看，递归确实没优势——它可能更慢、更占内存。但你学的不是“怎么求5!”，而是“如何用递归思维解决问题”。

4.2 递归的真正价值：处理“规模说了算”的结构

递归真正发光发热的场景，是那些本身具备“规模递减的重复子结构”的问题。比如二叉树的遍历——一个节点下挂着两个更小的子树，你要打印所有节点，用循环写遍历需要自己维护一个栈，代码绕来绕去；用递归写，一个函数就把“访问当前节点→递归访问左子树→递归访问右子树”表达完了。再比如统计某个文件夹下所有文件的总大小，目录里套目录，天然就是递归结构。汉诺塔问题也是：移动n个盘子，先移动n-1个盘子到辅助柱，再移动最大盘，再移动n-1个盘子到目标柱，定义本身就是递归的。在这些场景里，用递归不是为了炫技，而是因为“分而治之”的思路本身就是问题最自然的表达方式。

4.3 什么时候不该用递归：尾递归、记忆化与开销控制

递归不是银弹。三个典型“不该硬递归”的场景：

第一，递归深度过大。比如要递归处理一个深度达到上万层的目录树，或者用递归计算超大阶乘，函数调用栈可能直接溢出。C语言默认栈空间一般是1MB到8MB量级，每个栈帧看着不大，但深度一大就危险。

第二，存在大量重复计算。求斐波那契数列的朴素递归就是典型反例：fib(5)要算fib(4)和fib(3)，fib(4)又要算fib(3)和fib(2)，fib(3)被反复计算好几遍。指数级的时间复杂度，纯属浪费。应对办法是记忆化——用一个数组把算过的结果存下来，下次直接取。这样fib(5)的递归就从指数级变成线性级。

第三，能轻松用循环表达的任务。比如遍历数组求和、查找最大值，用循环几行结束，没必要递归。写代码的本质是表达清晰、维护简单，而不是刻意用某个技巧。

5. 递归代码最容易踩的坑：栈溢出、重复计算与手误

5.1 终止条件写错导致的段错误与调试方法

我自己第一次写阶乘递归时，把终止条件写成了n == 1，然后直接用factorial(0)测试，当场段错误。排查时最笨也最有效的方法是：在函数入口加一条printf打印当前n的值，看它是不是一路冲到负数。

long factorial(int n) { printf("enter factorial: n = %d\n", n); if (n <= 1) return 1; return n * factorial(n - 1); }

一旦看到输出里出现0、-1、-2这类不该出现的值，基本就能判定终止条件没覆盖到所有合法输入。修正成n <= 1之后问题消失。这条经验对任何递归函数都适用：优先验证边界值，别只测题目要求的那一个输入。

5.2 返回值写错：丢失当前层数据

还有一种很隐蔽的手误：把递归步骤写成

return factorial(n - 1); // 漏乘了 n

这个写法语法完全正确，也不会崩溃，但factorial(5)算出来还是factorial(4)的结果，最终得到1。问题在于当前层的n没有参与计算，数据在每一层被白白丢弃。这类逻辑错误比段错误更难发现，因为程序不报错，只给错误结果。排查思路是：检查递归步骤里是否把当前层的参数“用”了进去。阶乘的递归必须体现n，累加的递归必须体现n，幂的递归必须体现base——如果递归调用前后没有任何当前层数据的参与，那这个递归十有八九写错了。

5.3 递归深度太深时怎么办：三种思路

当你要递归处理的深度超过几万层，即使终止条件正确，程序也可能因为栈空间不足而崩溃。这时有几种调整思路：

一是改成循环实现。很多看起来“必须递归”的问题，实际用循环加显式栈也能写，只是可读性差点。二叉树遍历的迭代版就是典型。

二是使用尾递归优化。如果递归调用是函数体里最后一个操作，而且返回值直接作为函数返回值，某些编译器可以做尾递归优化，把递归调用转成循环，从而不新增栈帧。但C标准并没有强制要求编译器这么做，依赖它之前最好确认你用的编译器确实支持。

三是增加栈空间。一些环境和编译选项允许调整栈大小，但这属于“缓解”而不是“解决”，深层问题最好还是换算法或换写法。

提示：如果你在某个练习系统里提交递归代码却得到“超出内存限制”之类的错误，先别急着怀疑系统，看看你的递归深度是否过大、终止条件是否覆盖了所有分支。

5.4 递归的调试技巧：从“看图”开始

我给新手最大的建议是：别一上来就在IDE里硬调。先用手写出“调用树”，拿factorial(5)为例，把每个调用和每个返回值像链条一样列出来，再对照代码一步步走。这个动作看上去笨，但能最快帮你建立“递归 = 递推 + 回归”的心智模型。一旦你脑子里有了这棵树，调起错来就快很多——你会知道该在哪一层打断点，也该看到哪一层返回了意外的值。

我个人在实际写递归函数时，长期遵循一个简单习惯：先问自己三个问题——**这个函数的终止条件是什么？每次递归调用时问题规模怎么缩小？当前层的数据要不要参与计算？**三个问题都答清楚了，再动手写代码。递归这门手艺，本质上不是“写出能跑的函数”，而是“把一个规模递减的过程想清楚”。想清楚之后，代码往往就几行；想不清楚，调试多少个小时都绕不出来。希望这篇关于“求5”的拆解，能帮你把递归这个坎真正迈过去。