要理解Python中递归函数的行为，最简单的方式是观察一个打印整数序列的函数。假设我们需要按顺序输出从1到n的所有整数，常见的循环解法如下：
def print_forward_loop(n):
for i in range(1, n + 1):
print(i)
如果把这段逻辑改写成递归，它会变成下面的样子：
def print_forward(n, current=1):
if current > n:
return
print(current)
print_forward(n, current + 1)
print_forward(5)
执行print_forward(5)时，函数并不是一次性打印出所有数字。第一次调用进入函数后，先打印1，接着发起print_forward(5, 2)的调用。这时第一次调用并没有结束，而是被系统挂起，等待新调用返回。新调用同样会打印自己的当前值，再继续发起下一层调用。就这样，栈上会依次积压print_forward的多个栈帧，直到current超过n，最深层调用才执行return，然后从内向外逐个结束。这个过程中，每个栈帧都保存了函数参数、局部变量和返回地址，因此递归会同时消耗函数调用栈的空间和记录状态的时间。
一、递归调用轨迹的观察与追踪方法
调试递归函数时，最基础的手段是在函数入口和出口插入print语句。例如：
def print_forward(n, current=1):
print(f"进入函数，current={current}")
if current > n:
print(f"到达终止条件，current={current}")
return
print(current)
print_forward(n, current + 1)
print(f"返回上一层，current={current}")
print_forward(3)
执行后可以看到类似下面的输出：
进入函数，current=1 1 进入函数，current=2 2 进入函数，current=3 3 进入函数，current=4 到达终止条件，current=4 返回上一层，current=3 返回上一层，current=2 返回上一层，current=1
如果不想在业务逻辑里混入大量调试代码，可以使用装饰器统一追踪。装饰器会在原函数调用前后自动记录参数和返回值：
def trace(func):
def wrapper(*args, **kwargs):
print(f"进入 {func.__name__}，参数：{args}")
result = func(*args, **kwargs)
print(f"离开 {func.__name__}，参数：{args}，返回值：{result}")
return result
return wrapper
@trace
def print_forward(n, current=1):
if current > n:
return
print(current)
print_forward(n, current + 1)
print_forward(3)
这个装饰器会原样保留递归调用关系，因为print_forward内部调用的就是被装饰后的函数本身。追踪信息会清楚显示调用栈的后进先出特征：最先进入的函数最后离开，最后进入的函数最先返回。当递归层数不多时，这种输出已经足够定位问题；但当层数变深，输出会非常长，这时可以借助traceback模块在关键位置打印当前调用栈。
更精确的追踪可以借助sys.settrace。它允许设置一个全局追踪函数，每当代码进入函数、返回或发生异常时被调用。这样可以记录每一层递归调用的行号、函数名和事件类型。不过sys.settrace会显著拖慢程序运行，通常只在调试和覆盖率统计工具中使用，普通业务代码不必引入这种开销。
二、递归打印序列的性能瓶颈
递归调用最明显的开销是栈帧的创建和销毁。CPython解释器默认将函数调用栈的深度限制在1000左右，可以通过sys.getrecursionlimit()查看。如果序列长度达到1500，递归打印函数会在还没输出完之前就抛出RecursionError。即使通过sys.setrecursionlimit(5000)提高限制，也只是把问题延后，过深递归仍然可能触发C语言层面的栈溢出，导致解释器直接崩溃。
除了深度，递归生成列表的方式还可能造成严重的时间浪费。看下面这个例子：
def build_list_recursive(n):
if n == 0:
return []
return build_list_recursive(n - 1) + [n]
print(build_list_recursive(5))
这段代码每次递归返回时都要执行+ [n]，而列表拼接会创建全新的列表对象，并把左侧列表中的元素复制一遍。第1层复制1个元素，第2层复制2个元素，依此类推，整体时间复杂度为O(n²)。当n为10000时，它比简单的循环append慢出几个数量级。等价的循环版本如下：
def build_list_loop(n):
result = []
for i in range(1, n + 1):
result.append(i)
return result
print(build_list_loop(5))
循环版本只创建一个列表对象，并通过append在尾部追加元素，均摊时间复杂度接近O(n)。在Python中，列表扩容虽然有偶尔的重新分配，但整体效率远高于递归拼接。类似的差异也出现在使用list.insert(0, item)插入头部时，因为每次插入都要移动已有元素。
三、尾递归优化与显式栈改写
有些资料会提到尾递归优化，指的是当递归调用是函数体的最后一步操作，并且调用结果直接返回时，编译器或解释器可以复用当前栈帧，而不是创建新栈帧。可惜的是，CPython并没有实现尾递归优化。即使把序列打印写成下面这种看似尾递归的形式：
def print_reverse(n):
if n == 0:
return
print(n)
print_reverse(n - 1)
print_reverse(5)
递归调用print_reverse(n - 1)虽然已经是函数最后一步，但CPython仍然会为每次调用建立新的栈帧。你可以通过增大n来验证，它依旧会触发RecursionError。因此，在Python中讨论尾递归时，更多是为了理解递归结构，而不能指望它带来性能提升。
如果递归深度确实可能很大，同时问题本身又适合用栈来模拟，那么显式栈改写是一个可靠的替代方案。仍以正向打印序列为例：
def print_forward_stack(n):
stack = [1]
while stack:
current = stack.pop()
print(current)
if current + 1 <= n:
stack.append(current + 1)
print_forward_stack(5)
这个版本使用Python列表作为栈，每次弹出当前值并打印，然后判断是否需要把下一个值压入栈中。它不再依赖解释器的递归深度，也不存在递归栈帧的层层积压。对于更复杂的递归场景，如深度优先搜索、括号匹配、树的前序遍历等，都可以用显式栈保存待处理状态。显式栈的好处是栈的大小受堆内存限制，通常可以容纳远超默认递归深度的元素；缺点是代码可读性可能不如递归直观。
四、何时保留递归，何时改为迭代
递归并非一无是处。在处理树形结构、分治算法、组合枚举等问题时，递归代码往往比显式栈更容易理解和维护。例如遍历文件目录、解析嵌套配置、生成全排列，天然就是递归结构。用循环去模拟这些递归，经常需要手动维护多层状态，反而容易引入边界错误。因此，只要递归深度在安全范围内，并且单层递归内部没有大量耗时操作，保留递归是合理的选择。
判断是否改写迭代，可以关注三个信号。第一，序列长度或输入规模可能超过默认递归深度；第二，递归过程中存在不必要的重复计算或对象拼接，比如斐波那契数列的朴素递归和刚才的列表拼接递归；第三，性能剖析工具显示函数调用本身占据了主要耗时。对于第一个信号，可以先尝试优化算法，再考虑sys.setrecursionlimit或显式栈；对于第二个信号，通常改为循环并复用可变对象收益明显；对于第三个信号，则需要重新设计递归边界，减少无效调用。
最后回到序列打印这个问题。单纯打印1到N，循环永远是最直接的选择；如果需要反向打印，也完全可以使用for i in range(n, 0, -1)。只有当你需要借助递归的思想解决更复杂的嵌套序列或树状结构时，才有必要在代码中保留递归，并配合装饰器、traceback或显式栈等手段来追踪和控制调用过程。理解这一点，比记住某个具体写法更重要。