协程栈溢出是因局部变量或调用深度超出预分配栈空间（默认8KB），导致SIGSEGV崩溃或静默失败，而非内存耗尽；需通过set或go指定stack_size预防，并规避递归、大数组、深闭包等风险模式。
协程栈溢出不是“内存用光了”那么简单，而是协程执行时局部变量或调用深度超出了预分配的栈空间上限，默认 8KB 很容易被大数组、深层递归或嵌套闭包打穿。它不会报 MemoryError，而是直接 SIGSEGV 崩溃或静默失败，尤其在 Co\run 或 go 内部触发。
协程栈大小默认值与实际影响
Swoole 协程默认栈大小为 8KB（SWOOLE_DEFAULT_STACK_SIZE），远小于线程栈（2MB+）。这个值对简单 I/O 操作足够，但一旦出现以下情况就极易溢出：
- 函数内定义超大数组（如
range(1, 100000)） - 递归调用未设终止条件，或深度 > 200 层
- 闭包嵌套过深 + 捕获大量外部变量（
use ($a, $b, $c, ...)） - 使用
json_encode或serialize处理嵌套极深的对象
注意：栈大小不可运行时动态调整，必须在协程启动前配置。
如何安全扩大协程栈空间
扩大栈空间是最快见效的预防手段，但不能无脑调高——过大会浪费内存池，且掩盖真实设计问题。推荐按需分级设置：
- 全局统一扩大（适用于多数业务）：
Swoole\Coroutine::set(['stack_size' => 256 * 1024]); // 256KB - 单次协程覆盖（高风险操作专用）：
go(function () { /* ... */ }, ['stack_size' => 1024 * 1024]); // 1MB - 避免在
Co\run中设置，它不接受stack_size参数
超过 1MB 栈空间需谨慎：Swoole 内存池会为其预留连续页，可能引发 mmap 失败或增加内存碎片。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
比调栈更关键的代码避坑点
栈溢出本质是执行路径失控，单纯扩栈治标不治本。真正要卡住的是危险模式：
- 禁用深度递归：用迭代替代递归，或加
$depth <= 50硬限制 - 大数组分块处理：避免
$data = file_get_contents()后直接json_decode($data)，改用流式解析 - 闭包只捕获必需变量：写成
use ($id)而非use ($this)；若必须持对象，确认其不含循环引用 - 警惕
debug_backtrace()和var_dump()：它们在协程栈中生成巨量临时结构，生产环境必须移除
特别注意：yield 不释放栈空间，挂起协程时整个栈帧仍驻留堆中。
上线前必须做的栈压力验证
仅靠本地测试无法暴露栈问题，必须模拟真实负载路径：
- 用
strace -e mmap,munmap观察协程创建时是否频繁失败 - 在
onWorkerStart中注入检测：Swoole\Timer::tick(5000, function () { echo "Stack OK\n"; });—— 若该定时器突然停止输出，大概率已有协程因栈溢出崩溃 - 压测时监控
cat /proc/$(pidof php)/status | grep VmStk，持续 > 1MB 就需排查
协程栈溢出最麻烦的地方在于：它不抛异常，不进日志，只让 Worker 进程无声退出。所以预防的关键不是“怎么救”，而是“怎么让它根本没机会溢出”。
