ulimit -s仅临时扩大进程栈上限，治标不治本；真正解决栈溢出须优先消除无限递归、改用迭代、避免大局部变量、将大对象移至堆分配，并加递归深度守卫。
能调，但 ulimit -s 只治标不治本——它改的是整个进程的用户态栈上限，对递归逻辑本身没任何约束力。
ulimit -s 查看和临时修改栈大小
执行 ulimit -s 就能看到当前 shell 进程的栈限制（单位 KB）。默认通常是 8192（即 8MB），对深度递归函数来说很容易耗尽。
临时加大到 16MB 只需：
ulimit -s 16384
注意：ulimit 修改只影响当前 shell 及其后续启动的子进程，关掉终端就失效。不能在已运行的程序中动态生效，也不能只针对某个函数或线程单独调大。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
在 Bash 脚本里加 ulimit -s 不等于“递归更安全”
很多人以为在脚本开头写 ulimit -s 32768 就高枕无忧了，其实有三个关键盲区：
- 如果脚本用
#!/bin/sh启动，而系统里sh是 dash 或其他非 bash 的 shell，ulimit命令可能根本不被识别 - 即使生效，也只是给整个进程划了更大一块栈空间；若递归函数每次调用都分配大数组（比如
char buf[65536]），仍可能几层就撑爆 - Bash 自身的函数调用栈管理效率不高，实测在 1000 层左右就容易出
Segmentation fault，远低于理论栈空间能容纳的调用帧数
真正该优先做的：砍掉递归，而不是堆栈
ulimit 是兜底手段，不是优化路径。遇到栈溢出，第一反应不该是“再调大一点”，而是检查是否必须递归：
- 用循环重写常见模式：阶乘、树遍历、链表反转等，几乎都能转成迭代，局部变量复用，栈占用恒定
- 避免在递归函数内声明大数组：
int data[10000]每层吃掉 40KB，10 层就是 400KB，比函数调用开销高几个数量级 - 若必须递归，把大对象移到堆上：用
malloc或new分配，传指针而非值；Bash 里则改用全局数组或declare -g变量缓存状态 - 加深度守卫：在 Bash 递归函数开头判断当前层级，超限直接
return 1，比硬崩更可控
ulimit -s 调得再高，也挡不住无限递归或每层疯狂压栈的行为；真正决定栈是否溢出的，从来不是数字，而是代码怎么用栈。
