递归深度超栈限制会直接崩溃，因系统栈空间有限（Windows默认1MB，Linux通常8MB），简单阶乘在n≈100000时即溢出；须加深度防护、慎用尾递归优化、改用显式栈或循环。
递归深度超过系统栈限制会直接崩溃
Windows 默认线程栈是 1MB，Linux 通常是 8MB（但可被 ulimit 限制），而每次函数调用至少压入返回地址、局部变量、寄存器备份——哪怕 int n 和 return n == 0 ? 1 : n * fact(n-1) 这种简单阶乘，在 n ≈ 100000 时就大概率炸栈。这不是代码逻辑错，是资源硬边界。
- 用
ulimit -s查当前栈大小（Linux/macOS），GetThreadStackLimits或调试器看 Windows 实际值 - 递归前加深度防护：比如传入
depth参数，超过1000就throw std::runtime_error("recursion too deep") - 别依赖编译器优化：
tail recursion在 C++ 中几乎不被 GCC/Clang 自动优化成循环，除非函数严格满足尾调用形式且开启-O2以上，但依然不可靠
哪些递归天生容易栈溢出？
树形结构遍历（如二叉树深度优先）、分治类算法（如快排最坏情况）、未剪枝的回溯（如全排列、N 皇后）——它们的调用深度直接取决于输入规模，而不是常数。
- 二叉树遍历：链状退化树（所有节点只有右子节点）会让
inorder(node->right)深度达到N层，必须改用显式栈模拟 - 快排：选基准不当导致每次只排除一个元素，递归深度
O(N)；应改用三数取中 + 尾递归优化（对较小段迭代处理） - 回溯：加剪枝条件不够强时，比如
if (current_sum > target) return;比没判断好，但不如预排序后从大到小试值来得早停
把递归改非递归，关键不是“套模板”，而是盯住状态
递归本质是隐式维护一个调用栈，你手动建个 std::stack，里面存的不是“下一步要算什么”，而是“当前层还没做完的事”。比如 DFS 遍历，栈里该存的是 TreeNode*；但如果是带状态的递归（如背包问题中的 (i, w)），栈里就得存 struct { int i; int w; };
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要一上来就写
while (!s.empty()) { auto x = s.top(); s.pop(); ... }——先画两层递归调用栈帧，看哪些变量跨层共享、哪些每层独立 - 局部变量提升为栈元素字段：原递归函数里的
int sum、std::vector<int> path</int>，在迭代版里通常要作为结构体成员和栈一起推入 - 注意执行顺序：递归是“进左→进右→回退”，手动栈需按相反顺序压入（先压右再压左），否则遍历顺序错乱
用迭代替代递归后，性能和可读性未必双赢
手动栈确实消除了栈溢出风险，但引入了额外内存分配（std::stack 底层用 deque 或 vector）、缓存不友好（指针跳转）、以及更复杂的控制流。有些场景，不如换思路。
立即学习“C++免费学习笔记（深入）”；
- 能用循环解决的，别硬套栈：比如斐波那契、阶乘、累加——这些本就是尾递归，直接写
for最干净 - 数据结构本身支持迭代：
std::list、std::vector的遍历，用迭代器比模拟栈直观得多 - 真需要深递归又不想改逻辑？考虑切换线程栈大小：
pthread_attr_setstacksize（POSIX）或 Windows 的CreateThread第三个参数，但这是权宜之计，不解决根本的算法复杂度问题
栈溢出背后往往不是递归写法的问题，而是没意识到输入规模和调用深度之间的线性/指数关系。压栈动作本身很快，慢的是你没拦住那个本不该发生的万层调用。
