Linux下递归深度无系统级直接指标，仅能通过getrlimit(RLIMIT_STACK, &rlim)获取栈空间硬限制rlim.rlim_cur（如8 MiB），再结合每层栈帧开销估算理论深度，但实际受编译器优化、红区等影响，需实测崩溃点或gdb backtrace确认真实深度。
Linux下用getrlimit查栈大小限制，不是递归深度
程序的“递归调用最大深度”没有操作系统级的直接指标——它由每个线程的栈空间大小和每次递归调用消耗的栈帧共同决定，不是某个预设的整数上限。真正能查到的是栈空间硬限制：RLIMIT_STACK。调用getrlimit(RLIMIT_STACK, &rlim)返回的rlim.rlim_cur（单位字节）才是关键数值，比如常见值是8 MiB（8388608）。注意：这限制的是整个线程栈，不是专为递归保留的。
递归深度得自己估算，不能靠系统API直接读取
假设函数每次递归调用压入约256字节栈帧（含返回地址、参数、局部变量、对齐填充），那在8 MiB栈限制下理论极限约32768层；但实际远达不到——函数调用开销、编译器优化、栈红区（guard page）、信号处理栈等都会挤占空间。更可靠的做法是实测崩溃点：
- 写一个简单递归函数（如
void recur(int n) { recur(n+1); }） - 用
ulimit -s临时调整栈大小验证变化 - 捕获
SIGSEGV或观察Segmentation fault (core dumped)出现时的n值
Windows下用GetThreadStackLimits或PE头获取预留栈大小
Windows不提供运行时动态栈限制查询接口，主线程栈大小由可执行文件PE头中的SizeOfStackReserve字段决定（链接时由/STACK指定，默认1 MiB）。可用GetThreadStackLimits(&low, &high)获取当前线程实际已分配/预留范围，但该API仅从Windows 8/Server 2012起可用，且返回的是地址边界，需自行换算字节数。注意：该值不反映剩余可用空间，只反映初始分配策略。
调试时用backtrace和addr2line看实际调用链长度
当递归过深导致崩溃，用gdb加载core dump后执行bt可看到当前栈帧数量（即已发生的递归层数），这是最真实的“当时深度”。若想在运行中监控，可在递归函数入口加计数器并定期输出，但要小心计数器变量本身也占栈空间。另外，启用-fno-omit-frame-pointer编译选项能让backtrace更准确，否则优化可能内联或省略帧指针，导致层数统计偏少。
立即学习“C++免费学习笔记（深入）”；
实际递归安全边界取决于函数体复杂度、编译器、目标平台和运行时环境，没有统一数字。别依赖“系统报告”，动手测+留余量才是正解。
