间接递归是函数A调用函数B、B再调用A形成的循环调用；直接递归是函数直接调用自身。二者均需明确退出条件，但间接递归涉及多函数协作、调试更难、易受栈深度限制，适用场景有限。
什么是间接递归，和直接递归有什么区别
间接递归就是函数 A 调用函数 B，B 又调用 A，形成调用闭环；而直接递归是函数自己调自己。foo() 调 foo() 是直接递归，even() 调 odd()、odd() 又调 even() 就是间接递归。关键在于：它不是语法糖，而是靠两个（或多个）函数协作维持状态，常用于状态机、奇偶判断、协程模拟等场景。
Python 中实现间接递归要注意栈溢出和终止条件
Python 默认递归深度限制约 1000 层，间接递归同样受此约束。若没设好出口，even(1000) → odd(999) → even(998) … 会很快报 RecursionError: maximum recursion depth exceeded。必须确保每次调用都向基例靠近，且基例能被任一函数单独处理。
常见写法示例：
def even(n):
if n == 0:
return True
return odd(n - 1)
<p>def odd(n):
if n == 0:
return False
return even(n - 1)这个例子看似简洁，但有隐患：even(-1) 会无限调用下去。所以实际使用时应加输入校验：
- 统一在入口函数做参数检查，比如只接受非负整数
- 避免让两个函数都承担“兜底”逻辑，建议由其中一个负责边界处理
- 若需支持大数值，改用迭代或尾调用优化（Python 不原生支持，需手动展开）
JavaScript 中间接递归容易因 this 或作用域丢失出错
JS 里如果用方法形式写间接递归（比如对象里的 checkEven 和 checkOdd），常见错误是 this.checkOdd() 在调用链中丢失上下文，导致 TypeError: this.checkOdd is not a function。这不是递归问题，是绑定问题。
解决方式很直接：
- 用箭头函数定义方法（不绑定
this，依赖外层作用域） - 在构造函数/类中显式绑定：
this.checkOdd = this.checkOdd.bind(this) - 更推荐函数声明或模块顶层函数，避开
this纠纷
例如：
const parity = {
even(n) {
if (n === 0) return true;
return this.odd(n - 1); // 必须确保 this 指向 parity
},
odd(n) {
if (n === 0) return false;
return this.even(n - 1);
}
};但如果把 parity.even 单独取出来赋值给变量再调用，this 就崩了——这点比 Python 更容易踩坑。
间接递归的性能和可读性代价常被低估
它看起来像“分而治之”，但每次调用都有函数栈开销，且调试时调用栈是交错的（A→B→A→B…），打断点或看 traceback 会比单函数递归更难追踪。某些语言（如 Go）甚至默认禁止尾调用优化，间接递归无法被编译器优化成循环。
真正需要它的时候其实不多：
- 状态明确二分（如解析器中
parse_expr调parse_term，后者又可能回调前者） - 异步流程中模拟协同控制流（如
step1resolve 后调step2，step2reject 时回退到step1的重试逻辑） - 教学演示“函数即值”的语言特性
多数业务逻辑里，用布尔标志 + 单循环或状态枚举更清晰。间接递归不是炫技工具，而是特定结构的自然表达——用之前先问一句：这个循环调用关系，真的不能扁平化吗？
