Swoole协程嵌套时create()无效因调度器不主动切换，需I/O操作或co::sleep(0)让出控制权；go()更安全但上下文不透传、异常不冒泡、Channel易死锁，defer行为在5.x有变化。
协程嵌套时 Swoole\Coroutine::create() 为什么没效果
直接在协程里再调 Swoole\Coroutine::create()，新协程大概率不执行——不是语法错，是调度逻辑问题。Swoole 的协程调度器默认只在「顶层协程」或「明确 yield 的点」才切换，嵌套调用 create() 后若没主动让出控制权（比如没调 co::sleep()、没发 HTTP 请求、没读文件），调度器根本不会去跑你新启的协程。
- 必须配合 I/O 操作或显式让出：比如在
create()后立刻调co::sleep(0)，或确保新协程内至少有一次co::sleep()/co::httpGet()/co::readFile()等可挂起操作 - 更稳妥的做法是改用
go(function () { ... })：它内部已处理好调度入口，语义更清晰，且兼容 Swoole 4.8+ 的自动协程调度优化 - 注意
create()返回的是协程 ID（int），不是可 await 的对象；别把它当 Promise 用，也别试图用yield直接等待它
go() 嵌套调用是否安全？哪些参数会丢失
go() 本身是线程安全的，但嵌套调用时，父协程的上下文（比如 Co::getuid() 返回的协程 ID）不会自动透传，变量作用域仍是 PHP 原生规则——闭包外的变量需显式 use，否则拿不到。
- 协程局部存储（
Co::set() / Co::get()）不会继承：子协程里Co::get('foo')拿不到父协程设的值，得手动传参或改用context类库（如swoole/library中的Context） - 异常不会跨协程冒泡：子协程抛异常，父协程收不到，除非你用
Channel主动传递错误信息 - 如果嵌套层级深（比如 5 层以上
go()），要注意栈内存占用——Swoole 默认协程栈是 2MB，虽可调，但没必要靠堆叠来设计逻辑
协程嵌套中 Channel 阻塞导致死锁的典型场景
最常见的是：父协程 pop() 等子协程 push()，但子协程还没启动完，或子协程自己也在等另一个 Channel，形成环状等待。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 永远不要在同一个协程里对同一
Channel先pop()再push()：这等于自己卡自己，连go()包一层都救不了 - 用
Channel->pop(0.1)加超时，而不是无期限阻塞；生产环境务必设超时，哪怕 10ms - 调试时可用
Co::stats()查当前活跃协程数和 Channel 状态，Channel->length()和Channel->capacity()要心里有数——满容量 + 阻塞写 = 卡住整个协程调度链
Swoole 5.x 协程嵌套的兼容性坑：defer 和 finally 行为变化
Swoole 5.0 起，协程退出时 defer 函数执行时机变了：它现在严格按「协程结束前」触发，而不是「函数返回前」。这意味着嵌套协程里注册的 defer，可能在父协程还没结束时就被清掉了。
- 别依赖
defer做跨协程资源释放：比如子协程开了 MySQL 连接，用defer关，但父协程还拿着这个连接句柄，就可能报MySQL server has gone away -
try/catch/finally在协程内正常工作，但finally不保证在协程被Co::cancel()时执行——取消协程会跳过finally，这点和普通 PHP 不同 - 真正需要兜底释放的资源（如临时文件、锁），建议统一走
Co::defer()（注意是静态方法），它绑定到当前协程生命周期，比函数内defer更可靠
嵌套协程真正的复杂点不在语法，而在「谁在什么时候释放什么资源」「错误从哪一层漏出来」「超时控制要设在哪一层」——这些没法靠一个 go() 解决，得根据实际 I/O 链路画清楚边界。
