递归这东西，落地干活的时候，往往感觉像个没写完的代码块，卡在那儿，死活除不尽。 在计算机这行当里，递归就是一场自己找死又自己找生的表演，核心逻辑就是：函数要调用它自己。
听起来像自杀，真没点难度。
比如我们要算一个斐波那契数列，定义就挺粗暴。前两个数是啥就啥，从第三个启动呢？前一个加前一个？别急，要是是 1000 个数字，这样加完加完，程序就死在那儿了，内存爆炸，栈溢出。
这时候就得搞个“子函数”，把大难题切成小难题，小难题再切成更小的，直到遇到一个能直接算出来的根本块，比如 10 要么 0，然后再慢慢往上拼。
这种“把大石头砸成小石子，再砸成更小的碎石头，直到能用手接住为止”的过程，就是递归的魅力。 那我们看看代码里具体咋干的。
比如计算阶乘，3! 等于 6。
这玩意儿挺好办，直接写个注释要么公式就行。但要是改成递归呢？那就得先让函数自己喊自己：“嘿，你算算 3 的阶乘吧，我算 2 的，你算 1 的，加起来。”然后它接着算 2 的阶乘，再算 1 的，再算 0 的，这时候它又得喊自己：“你算算 2，我算 1。”这就形成了无限循环。但在计算机眼里，这不是无限，这有一个“最大递归深度”。一旦栈里的栈帧堆得忒厚，电脑就提示空栈毛病。
这时候就得用尾递归优化，要么干脆暴力迭代来替代。递归之故此实用，是出于它天然地贴合了人类解决难题的思维模式：大难题分解为子难题，子难题持续分解。 举个具体的例子，假设我们要遍历一个链表并求和。链表结构是头节点，后面跟着若干节点，每个节点存个数字。直接写死循环，就得从头往后扫，还得回头去算每一步的和，效率低。用递归就顺了，函数指着链表里的头节点：“嘿，我走到头了，才 1 个数字，直接给你回。”然后它把数字加到结局里，接着回过头去，函数指着第二个节点：“我走到这儿了，还有 1 个数字，持续。”递归到底部，每个节点都去调用自己，然后头节点把收到的回值，加上自己节点里的数字，最终把所有结局加起来回给最初的主函数。
这时候代码就通了，并且逻辑清楚，一看就知道啥时候终止，啥时候持续。 这种写法在画画的时候特别好用。
比如画一棵二叉树，先画根节点，然后递归去画左右两棵子树。画完根，回头去画左子树，再画右子树。递归的精髓就在这儿，它不需求一个循环变量去变量之间传数据，而是依靠函数的“自我”调用，把管住流自动调度得挺好。
哪怕函数调用堆得再深，只要里面的逻辑是线性的，没有死循环，它就能跑通。就像爬楼梯，递归就是你自己一步一步往上摸，每摸一步，就记一步，直到爬到顶，再往下算总高度。 不过，递归可不是能无限使用的傻工具。
每次调用函数，电脑都得在内存里开辟一个临时环境，包含栈帧，保存变量和回地址。
要是调用次数忒多，比如 100 万次，这内存消耗绝对没你想的那么好办。别看现代 CPU 处理这种动态调度挺快，但递归最致命的伤，往往不是内存量，而是“深度”。
要是树长得忒高，要么列表忒长，递归就会撞墙。
这时候，退而求用循环迭代往往更稳妥，别看要写点额外代码，但逻辑更稳，也没那么好办被系统直接拒之门外。 再想想数学里的例子。求数列 2^n 的和。用递归写，代码长度都不长，逻辑一目了然。每一层处理一个指数，然后回上一层的总和。
这就像剥洋葱，一层层剥开，直到剩下最中心的点。一旦到了最内层，比如 n=0 的时候，结局就是 1，这就有了基准情况，递归才能停。
要是连基准情况都没有，要么基准情况算错了，整个系统就崩塌了。
这时候，程序员得走过来，盯着代码，一句一句地改，要么多写个 if 判断，要么换个公式直接算。 实际上，递归在大量高级算法里都是神器。
比如快速排序、归并排序、堆排序，就连 Python 里的分治算法。它们都依赖递归的“分而治之”思想。把一个大难题切分成几个同样规模的小难题，然后单独解决这些小难题，最终把结局拼起来。
这就是递归的内核。只不过，不同层级的递归，效率可能天差地别。浅层的递归，就像做菜，顺手就能做出来；深层的递归，就像在没电梯的老旧小区里爬楼，每上一层，风险就大一倍，对身体的消耗也是直线上升。 故此说，递归在编程界地位挺高的，但不是万能的。它像是双刃剑，用得好，能写出优雅、简洁的代码，让逻辑变得透明；用不好，好办陷入死循环要么爆栈，代码变得晦涩难懂。作为开发者，得时刻提醒自己，写递归的时候，先问问自己：这个情况到底能停在哪？停在哪，是不是稳当的？要是答案是否定的，别硬凑，用循环要么动态规划一般更靠谱。递归是解决难题的有力武器，但别让它变成解决难题的枷锁，得知道啥时候用，啥时候别用，这才是专家思维。