高性能递归程序的关键是稳、快、省，需在正确性基础上规避性能陷阱：终止条件须严格、可判定且每次调用趋近；复杂判断（如多条件嵌套、浮点比较）易致开销大或栈溢出。
写高性能递归程序，关键不在“能不能跑通”，而在“能不能稳、快、省”。它不是单纯套用三要素就能自动高效，而是要在正确性的基础上主动规避常见性能陷阱。
明确且收敛的终止条件
终止条件必须严格、可判定，并确保每次调用都向它靠近。如果判断逻辑复杂（比如多条件嵌套或浮点比较），不仅增加开销，还容易漏判导致栈溢出。例如计算斐波那契时，用 n 比 n == 0 || n == 1 更简洁安全；处理树结构时，用 node == null 而非先判子节点再递归，避免多余访问。
- 避免在终止判断中做耗时操作（如文件读取、网络请求）
- 优先使用整型或引用判空等低成本判断
- 对输入做预校验，防止非法参数绕过终止逻辑
问题规模必须单调递减
每次递归调用传入的参数，必须使问题规模稳定缩小——这不是“大概变小”，而是数学上可证明的严格递减。比如遍历链表时用 head.next，二分搜索用 mid ± 1，阶乘用 n - 1。若出现参数不变（如误写成 f(n)）或增大（如 f(n + 1)），程序必然崩溃或无限循环。
- 递归深度应与输入规模呈线性或对数关系，避免指数级膨胀
- 对树类结构，注意最坏情况（如退化为链表）下的深度是否可控
- 必要时引入深度计数器，在超限时主动抛出异常而非硬扛
消除重复计算与冗余调用
朴素递归常因相同子问题被反复求解而效率骤降。典型例子是未优化的斐波那契：f(5) 会多次重算 f(3)、f(2)。解决方式不是“少调几次”，而是从结构上剪枝：
- 用记忆化（memoization）缓存已算结果，查表优先于重算
- 改用尾递归形式（语言支持时），让编译器有机会优化为循环
- 对可迭代替代的场景（如简单累加、遍历），直接用循环更稳妥
- 避免在递归体内创建大量临时对象或字符串拼接
控制栈空间与调用开销
每层递归都要压栈保存上下文，深度过大极易触发栈溢出。Python 默认限制约 1000 层，C/Java 虽更高，但业务数据量大时仍需防范：
- 对深度敏感场景（如解析深层嵌套 JSON），考虑手动模拟栈的迭代实现
- 减少递归函数参数数量和体积，避免传递大数组或对象副本
- 将非必要局部变量移出递归作用域，或复用已有变量
- 异步或分片处理超大规模问题，避免单次递归承载过多
