C++无法直接获取递归最大深度，因其由运行时栈空间与单帧开销共同决定；getrlimit(RLIMIT_STACK, &rlim)仅返回进程栈软限制字节数（如8 MiB），需除以动态变化的单帧开销估算深度，但该值受编译优化、局部变量大小等因素影响而不可靠。
Linux下用getrlimit获取栈大小限制
程序能递归多深，本质取决于每个函数调用占用的栈空间和系统允许的总栈大小。C++标准不提供直接查“递归深度上限”的接口，但可以通过getrlimit读取RLIMIT_STACK拿到当前进程的栈大小软限制（单位字节），这是实际起作用的边界。
注意：这个值是**栈总容量**，不是“还能递归多少层”——每层消耗多少栈帧，取决于参数数量、局部变量大小、编译器优化程度等，没法静态换算。
-
getrlimit(RLIMIT_STACK, &rlim)返回的是rlim.rlim_cur（软限制），通常默认为8MB（即8388608字节） - 若程序用
ulimit -s改过栈大小，这里会反映新值；root用户还能通过setrlimit临时调高 - 该限制对主线程有效，但对pthread创建的线程不生效——它们的栈大小由
pthread_attr_setstacksize单独控制
Windows下用GetThreadStackLimits判断当前线程栈边界
Windows没有rlimit机制，但提供GetThreadStackLimits（Win8+/Server 2012+）来获取当前线程的栈上下界地址，从而估算剩余可用栈空间。
它不返回“最大深度”，但配合GetCurrentThread和当前栈指针（比如取&some_local_var），能算出已用栈大小，进而预估还能压多少帧——这比硬编码递归计数更贴近真实崩溃点。
立即学习“C++免费学习笔记（深入）”；
- 函数原型：
GetThreadStackLimits(&low_limit, &high_limit)，返回的是虚拟内存地址范围 - 需用
char* sp = (char*)&i;（i为局部变量）获取当前栈顶，再计算sp - low_limit得已用字节数 - 旧系统（如Win7）只能靠
__try/__except捕获EXCEPTION_STACK_OVERFLOW做兜底
运行时检测栈溢出比预估深度更可靠
无论Linux还是Windows，试图提前算出“最多递归N层”都容易出错：编译器内联、尾递归优化、调试/发布模式差异都会让单层开销波动很大。实际项目中，更稳妥的做法是让递归函数自己监控栈使用。
- 在递归入口处用
char probe[1024]或alloca(1)触发栈分配失败（配合setjmp/longjmp或SEH） - 或维护一个递归深度计数器，结合经验阈值（如>1000层）主动抛
std::runtime_error——这虽不能防溢出，但能避免无限递归拖垮程序 - Clang/GCC的
-fsanitize=stack可在运行时报栈溢出，但仅用于开发阶段，性能损耗大
为什么不能依赖编译器或标准库提供的“最大递归深度”常量
C++标准完全不规定栈大小或递归限制，所有相关行为都是实现定义。不同平台、不同ABI、甚至同一编译器的不同优化等级（-O0 vs -O2）都会导致单次调用栈帧尺寸变化。
-
std::stack或std::vector模拟递归时，堆空间不受RLIMIT_STACK约束，但要自己管理状态，代码复杂度上升 - 某些嵌入式工具链（如ARM GCC）提供
__stack_limit符号，但它是链接时固定值，无法反映运行时setrlimit的修改 - 即使知道栈总大小，也无法安全换算成层数——例如一个带大数组的递归函数，一层就吃掉几KB，而空函数可能撑到上万层
真正关键的不是“理论最大深度”，而是你的递归逻辑是否真需要深度优先遍历，以及能否用迭代+显式栈替代。栈限制只是表象，设计上规避深层递归才是根本解法。
