c++标准不保证尾递归优化（tco），是否优化取决于编译器、优化等级及函数结构；即使写成return factorial_tail(n-1, n*acc)形式，局部对象析构、异常处理、虚函数调用等也会使gcc/clang放弃优化。
不会。C++ 标准不保证尾递归优化（TCO），是否优化完全取决于编译器实现、优化等级、函数结构和上下文环境。
为什么 return factorial_tail(n-1, n * acc) 仍可能不被优化
即使代码写成标准尾递归形式，以下情况会让 GCC 或 Clang 主动放弃优化：
- 编译时未启用优化（如用
-O0调试模式）——此时栈帧必增长，用于调试回溯 - 函数内有局部对象含非平凡析构函数（如
std::string、std::lock_guard），因为跳转会绕过析构逻辑，破坏 RAII 语义 - 存在异常处理（
try/catch）或setjmp/longjmp上下文，编译器无法安全复用栈帧 - 递归调用通过函数指针或虚函数进行（间接调用），编译器在编译期无法确定目标
如何确认你的尾递归真被优化了
不能靠“看起来像尾递归”就认为安全，必须实证：
- 用
g++ -S -O2 code.cpp生成汇编，搜索函数体内部：若看到jmp指令跳回函数开头（而非call），说明优化生效 - 运行大输入（如
factorial_tail(100000, 1)）并观察是否栈溢出；若溢出，说明没优化或被干扰 - 在 GDB 中单步执行，用
bt查看调用栈深度：尾递归优化后栈深应恒为 1
哪些写法看似尾递归实则无效
这些常见变形会让编译器直接判定为非尾位置，哪怕逻辑等价：
-
return func(x) + 0;—— 加法表达式包裹，破坏“裸调用”条件 -
auto res = func(x); return res;—— 中间变量引入，返回值不再直接来自调用 -
if (cond) return func(x); else return 42;—— 控制流分支后仍有其他返回路径，编译器难以统一跳转逻辑 -
return std::move(func(x));——std::move是函数调用，不是语言内置操作，尾位置被污染
真正可靠的防栈溢出方案，从来不是赌编译器会不会做 TCO，而是提前设计迭代版本、加深度守卫、或用显式栈模拟递归状态——毕竟栈空间是硬限制，而编译器优化是软承诺。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
