递归转迭代需先判断是否尾递归：是则用循环+变量替换；否则须用显式栈或生成器模拟调用上下文，同时注意性能权衡。
递归转迭代的核心判断：函数是否天然支持尾递归优化？
Python 解释器不支持尾递归优化（TCO），sys.setrecursionlimit() 只是临时补丁，不能解决本质问题。真正要消除栈溢出，必须显式改写为迭代——不是所有递归都适合直接“套模板”，关键看调用结构：如果函数在返回前只做一次递归调用（且无后续计算），属于尾递归，可直接用循环+变量替换；若存在多次递归调用、或递归后还要做运算（如 return f(n-1) + f(n-2)），就必须引入显式栈模拟调用上下文。
用显式栈模拟递归调用：以 DFS 遍历二叉树为例
常见错误是只把递归函数体改成 while 循环，却忘了保存“当前节点该处理哪部分”的状态。比如中序遍历，递归版本隐含了“先左、再根、后右”的执行顺序，迭代时需用栈存节点+状态标记：
stack = [(root, 'left')] # 元组：(node, stage)
while stack:
node, stage = stack.pop()
if node is None:
continue
if stage == 'left':
stack.append((node, 'visit'))
stack.append((node.left, 'left'))
elif stage == 'visit':
result.append(node.val)
stack.append((node.right, 'left'))
这里每个 (node, stage) 等价于递归栈帧，stage 替代了“执行到哪一行”的隐式位置信息。漏掉 stage 或顺序错乱，就会跳过节点或无限循环。
避免手动维护复杂状态：用生成器 yield from 拆解嵌套递归
当递归逻辑本身是“分治+合并”结构（如归并排序、表达式求值），强行压栈易出错。可用生成器把每层递归变成可中断的子任务：
比如快速排序的 partition 后，左右子数组分别递归。迭代改写时，不必自己管理左右边界栈，而是：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 定义
def quicksort_iter(arr, lo, hi):返回一个生成器，yield出待排序区间 - 主循环用
for lo, hi in quicksort_iter(arr, 0, len(arr)-1):，每次拿到新区间就做 partition - 子区间通过
yield推入队列，而非压入栈——逻辑更贴近原递归意图
这种方式把“状态管理”交给 Python 的生成器状态机，比手写多字段栈更不易出错，也更容易调试。
性能陷阱：迭代未必更快，别盲目替换
迭代只是消除了栈溢出风险，但不一定提速。实际影响取决于：
-
list.append()/pop()在 Python 中是均摊 O(1)，但频繁小对象创建（如大量元组）会增加 GC 压力 - 原递归若被 C 扩展优化（如
os.walk内部实现），硬改成纯 Python 迭代反而更慢 - 深度优先场景下，显式栈往往比函数调用栈稍慢；但广度优先（BFS）用
collections.deque迭代，通常比模拟递归更清晰高效
真正该优先迭代的，是那些明确已知深度可能超千级、且递归逻辑简单（如链表翻转、树高计算）的场景。复杂业务逻辑递归，先 profile 看是不是真瓶颈，再决定动不动手。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
