workerman中递归触发stackoverflowerror是因为php默认栈约8mb且不可调，长连接下未收敛递归（如无重试限制的onmessage自调用、超深json解析、递归协议解析、定时器循环回调）持续压栈致c栈耗尽崩进程。
Workerman里递归调用为什么会触发StackOverflowError？
PHP默认栈大小有限（通常8MB左右），而Workerman长连接生命周期远超普通HTTP请求——一次连接可能持续数小时。如果业务逻辑中存在未收敛的递归（比如错误的消息重试、嵌套事件触发、或误用回调链），每层调用都会压入新栈帧，最终在某个连接上悄无声息地崩掉整个Worker进程，错误日志里只留一句StackOverflowError，连堆栈都打不全。
哪些递归场景在Workerman里特别危险？
以下写法在FPM下可能没事，但在Workerman常驻进程中极易爆栈：
- 在
onMessage里直接调用自身方法做“重试”，且没设最大重试次数或退避逻辑 - WebSocket消息解析时，对嵌套JSON结构用递归函数遍历，而客户端故意发超深嵌套（如100层{}）
- 自定义协议解析器中，用递归下降语法分析器处理非法包，遇到循环引用或畸形长度字段就无限深入
- 定时器回调里调用
$this->doSomething()，而该方法又注册了新的定时器并再次调用自己
怎么安全地替代深度递归？
核心原则：把调用栈转移到堆上，用迭代+状态机代替函数调用栈。
- 用
while循环 + 显式栈数组模拟递归：比如解析嵌套JSON，改用$stack = [$root]，每次array_pop()处理一个节点，再把子节点array_push()进去 - 消息重试改用延迟队列：不要
sleep(1); $this->handle($msg);，而是用Timer::add(1, function() use ($msg) { $this->handle($msg); });，并记录重试次数到连接上下文属性中 - 所有递归函数入口加深度守卫：比如
function parse($data, $depth = 0) { if ($depth > 50) throw new RuntimeException('Too deep'); ... }，数值按实际协议最大嵌套预估 - 禁用
pcntl_fork()或exec()类阻塞调用——它们会继承当前栈状态，进一步压缩可用空间
Workerman启动时能调大PHP栈吗？
不能。PHP本身不提供运行时修改栈大小的接口，ulimit -s只影响主线程，而Workerman子进程由pcntl_fork()生成，继承的是父进程启动时的栈限制。强行用setrlimit(RLIMIT_STACK, ...)在PHP里不可靠，且不同系统行为不一致。真正有效的做法是：从代码根上消灭无界递归，而不是指望扩容。
最容易被忽略的是——递归崩溃往往只发生在某个特定连接上，其他连接照常服务，所以监控memory_get_peak_usage()没用，得盯住Worker进程的exit status和segfault信号；一旦发现Worker频繁重启，立刻检查是否有未受控的递归路径。
