无法直接获取递归调用堆栈最大深度限制，因c++标准、操作系统和编译器均未定义或提供该指标；实际可用的仅有栈空间上限、单帧开销和当前调用深度等间接线索，且三者合起来仍非真正最大深度。
不能直接获取“递归调用堆栈最大深度限制”这个指标——C++ 标准不定义它，操作系统不暴露它，编译器也不提供运行时查询接口。你真正能拿到的只有间接线索：栈空间上限、单帧开销、当前调用深度近似值，三者缺一不可，但合起来仍不是“最大深度”。
getrlimit(RLIMIT_STACK) 返回的是字节数，不是层数
调用 getrlimit(RLIMIT_STACK, &rlim) 拿到的是主线程栈软限制（单位字节），比如 8388608（8 MiB）。但它和“还能递归多少层”毫无直接关系：
- 同一函数在
-O0下单帧可能占 128 字节，在-O2下压缩到 16 字节，深度估算偏差达 8 倍 - 局部变量大小决定帧开销：
char buf[65536]一出现，单帧就吃掉 64 KB，8 MiB 栈最多撑 128 层 -
std::thread创建的线程默认栈常为 2 MiB，不受ulimit -s影响，getrlimit对它仅作参考 - 该值对已运行进程无效，只作用于后续子进程；容器中可能被 cgroup 覆盖
backtrace() 或 std::stacktrace::size() 给的是当前深度，不是上限
backtrace() 返回写入缓冲区的帧地址数量，std::stacktrace::current().size()（C++23）返回帧数，二者都只是“此刻调用链长度”，不是“最多允许多少层”：
-
backtrace(buffer, 128)的返回值nptrs是实际捕获帧数，若真实深度 >128 就被截断，结果失真 -
std::stacktrace::size()依赖调试信息（-g）、优化级别（-O2可能内联掉帧）、编译器支持（GCC ≥13.2 / Clang ≥16） - 它包含
__libc_start_main等系统帧，不全是用户代码；递归爆栈前，size()可能仍是 3–5 - Windows 下需用
StackWalk64或GetCurrentThreadStackLimits，无统一跨平台 API
真正有用的不是“查上限”，而是守卫递归入口
所有可靠项目都放弃估算，改用显式 depth 计数——这是唯一可移植、可预测、可测试的方式：
- 递归函数签名必须带
int depth = 0参数，入口立即检查：if (depth > 1000) throw std::runtime_error("recursion too deep"); - 阈值设 1000 是保守值：8 MiB 栈 ÷ 4 KB/帧 ≈ 2000 层，留 50% 余量防局部变量波动
- 避免在递归体里构造大对象：
std::string s(10000)会瞬间拉高单帧开销，改用引用或提前计算 - 用
static thread_local int counter也可行，但不如参数显式——后者支持不同调用路径设不同阈值
复杂点在于：单帧开销无法静态预知，而栈溢出崩溃不抛异常、无法 catch，gdb bt 看到的才是真实撞墙深度。别花时间写“估算最大深度”的工具函数，把 depth 参数加进每个递归函数，比任何 getrlimit + backtrace 组合都更早、更准、更稳。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
