C++中不存在可获取或依赖的“递归最大深度”，它是栈空间与单帧开销动态博弈的结果；唯一可靠做法是显式计数+硬阈值守卫，主线程保守设为1000层。
不能获取，也不该依赖这个值。 C++ 标准不定义“递归最大深度”，它不是变量、不是常量、不是 API 可读的数字——它是运行时栈空间与单帧开销动态博弈的结果。试图查出一个“安全层数”再硬编码进逻辑，几乎必然在某次编译优化、某类输入或某个线程创建方式下失效。
getrlimit(RLIMIT_STACK) 返回的是字节数，不是层数
调用 getrlimit(RLIMIT_STACK, &rlim) 拿到的 rlim.rlim_cur 是主线程栈软限制（单位字节），比如 8388608（8 MiB）。但它和“还能递归多少层”之间隔着三道不可控变量：
- 单帧开销完全不确定：空函数可能只占 16 字节，带
std::string s(10000)的函数一帧就吃掉 >10 KB - 编译器优化影响巨大：
-O0下帧可能 128 字节，-O2下压到 32 字节，同一函数不同编译参数结果差 4 倍 -
std::thread创建的线程默认栈大小通常只有 2 MiB，且不受ulimit -s影响，getrlimit对它只是参考
backtrace() 或 std::stacktrace::size() 不等于递归深度
backtrace() 返回地址数量、std::stacktrace::current().size() 返回帧数，二者都只是当前调用链的快照，但：
-
backtrace()缓冲区大小必须预先指定，若真实深度超限（如 2000 层但只传了 128 元素数组），返回值就被截断，你拿到的nptrs是 128，不是真实深度 -
std::stacktrace要求 C++23 + GCC ≥13.2 / Clang ≥16，且依赖调试信息（-g）；-O2可能内联掉中间帧，size()显示 5 层，实际调用链是 50 层 - 它们包含 runtime 初始化帧（如
__libc_start_main）、信号处理帧等，不是你写的递归函数嵌套层数
真正有效的做法：自己计数 + 硬阈值守卫
所有可能递归的函数，都该显式带 int depth = 0 参数，并在入口做检查——这是唯一跨平台、跨编译器、跨线程、不依赖估算的可靠方案：
立即学习“C++免费学习笔记（深入）”；
- 阈值设多少？主线程保守取
1000；若已知栈限制为 8 MiB 且单帧约 4 KB，则理论上限 ≈ 2000，但留 50% 余量更稳妥 - 不要写
if (depth > MAX_DEPTH)再 throw，而是if (++depth > 1000) throw std::runtime_error("recursion too deep");，避免漏判第 1000 层 - 别指望尾递归优化自动救场：
return f(n-1) + 1这类非尾调用，GCC/Clang 在绝大多数场景下根本不会优化
复杂点在于“单帧开销”本身不可预测
同一个函数，在不同上下文里帧大小可能差一个数量级：局部变量是否构造、是否被优化掉、是否触发 red zone 使用、甚至栈对齐填充，都会改变单帧字节数。这意味着任何基于 “总栈空间 ÷ 预估帧大小” 的计算，本质上都是猜。真正值得投入精力的，不是算出那个虚幻的“最大深度”，而是让递归函数从设计上就不依赖隐式深度——加守卫、拆迭代、移大对象出栈。
