递归适用与否取决于问题是否天然递归或数据结构是否递归形态；避免重复计算需用记忆化或动态规划；尾递归和辅助函数可降开销；深度过大时可用显式栈迭代替代。
递归逻辑的简洁实现与复杂逻辑性能平衡，关键不在“选递归还是选迭代”，而在于理解问题结构、识别重复计算、控制调用深度。简洁性来自问题本身的分层本质，性能损耗则多源于无意识的重复或栈空间滥用。
明确递归是否真适合这个问题
不是所有能写成递归的问题都该用递归。真正适合递归的，通常满足两个特征：
- 问题定义天然递归（如阶乘、斐波那契、树遍历、汉诺塔）
- 数据结构具有递归形态（如链表、二叉树、嵌套JSON、文件系统目录）
如果只是循环累加或线性扫描，强行递归反而增加函数调用开销和栈风险，此时迭代更直接高效。
避免朴素递归带来的指数级重复
像斐波那契的原始递归：fib(n) = fib(n-1) + fib(n-2)，看似简洁，但fib(5)会重复算fib(3)两次、fib(2)三次……时间复杂度达 O(2ⁿ)。
解决方法不是放弃递归，而是引入缓存机制：
- 记忆化（Memoization）：用哈希表存已算过的
n → result，首次计算后直接查表 - 自底向上动态规划：把递归改成迭代，用数组或变量滚动保存中间结果
两者都能将时间复杂度降到 O(n)，空间上记忆化是 O(n)，滚动变量可压到 O(1)。
用尾递归或递归辅助函数降低开销
普通递归每层都要保留现场（参数、局部变量、返回地址），栈深度随 n 增长；而尾递归——即递归调用是函数最后一步操作——理论上可被编译器优化为跳转，避免新增栈帧。
例如判断回文，不用每次传子串（生成新字符串开销大），而是传索引范围：
-
isPalindrome(str, left, right)只移动指针，不复制数据 - 每轮只做常数操作，栈深度由字符串长度决定，而非子串数量
这类“递归辅助函数”在保持逻辑清晰的同时，显著减少内存和时间浪费。
必要时转向迭代，但不牺牲可读性
当递归深度可能超限（比如处理上万层嵌套树）、或语言不支持尾递归优化（如 Python 默认无此优化、Java 也不原生支持），主动改写为迭代是合理选择。
技巧是用显式栈模拟调用过程：
- 树的先序遍历：用 Stack 存节点，每次 pop 后 push 其右、左子节点
- DFS 搜索：把待处理状态压入栈，而非靠函数调用隐式维护
这样既规避栈溢出，又比纯 while+flag 更贴近原递归意图，代码依然易懂。
