尾递归优化是编译器将尾位置的递归调用替换为无栈跳转以复用栈帧，需同时满足：调用是最后一个操作、返回值直接传递、开启优化且平台支持。
尾递归优化本质是用跳转代替函数调用
尾递归优化不是语言标准特性，而是编译器在满足特定条件时主动把 return func(...) 这类调用替换成 jmp（或等价的无栈跳转指令），从而复用当前栈帧。它不改变语义，但彻底避免了栈增长——前提是编译器能识别出“尾位置”且目标函数与当前函数共享调用约定。
必须同时满足的三个条件
哪怕漏掉一个，gcc 或 clang 都不会触发 TCO：
- 递归调用必须是函数体中最后一个操作（即不能有后续计算，如
return f(n-1) + 1就不符合） - 递归调用的返回值必须直接作为当前函数的返回值（不能包在表达式里、不能赋给变量再返回）
- 编译器需开启优化（如
-O2），且目标平台和 ABI 支持栈帧复用（x86-64 通常支持，某些嵌入式平台可能禁用）
看一个典型对比：有/无 TCO 的汇编差异
以计算阶乘的尾递归版本为例：
int fact_tail(int n, int acc = 1) {
if (n <= 1) return acc;
return fact_tail(n - 1, n * acc); // ✅ 尾位置，纯返回
}开启 -O2 后，clang++ 生成的核心循环类似：
立即学习“C++免费学习笔记（深入）”；
fact_tail:
cmp edi, 1
jle .Lret
imul esi, edi
dec edi
jmp fact_tail # ← 注意：这里是 jmp，不是 call
.Lret:
mov eax, esi
ret而如果写成 return n * fact_tail(n-1)，就会看到反复的 call fact_tail 和 push/pop，栈深度随 n 线性增长。
为什么 C++ 标准不保证 TCO？
因为 C++ 允许在函数末尾执行析构（如局部对象、RAII 锁），而尾调用跳转会绕过这些逻辑。例如：
int buggy_tail(int n) {
std::lock_guard<std::mutex> lock(mtx); // 析构必须在函数返回前发生
if (n == 0) return 0;
return buggy_tail(n-1); // ❌ 即使看起来是尾调用，TCO 也会破坏 lock 的生命周期
}所以编译器必须保守：只要存在可能影响语义的栈展开行为（比如异常处理、析构、setjmp 上下文），就放弃优化。这也是为什么你不能靠 TCO 来规避栈溢出——它只是优化手段，不是语言契约。
