协程切换发生在C层而非PHP层，由Swoole在C层分配独立栈并保存/恢复寄存器状态，PHP无法感知上下文切换过程，debug_backtrace()不可用，且协程无法跨Worker迁移。
协程切换不是 PHP 层控制的，它发生在 C 层栈帧保存/恢复阶段，PHP 代码里看不到上下文切换过程。
协程栈空间由 Swoole 在 C 层分配，不是 PHP 的 zend_stack
Swoole 协程启动时，swoole_coroutine_create 会调用 make_context（Linux 下基于 ucontext，多线程环境用 fcontext）分配独立栈，大小默认 2MB（可配 coroutine.stack_size），远小于 OS 线程的默认栈（通常 8MB）。这个栈完全脱离 Zend VM 的执行栈，PHP 层的 debug_backtrace() 拿不到协程切换路径。
- PHP 层看到的“函数调用链”只是当前协程正在执行的部分，不是整个调度轨迹
- 栈指针（
rsp）、指令指针（rip）、寄存器状态（如rax,rbx）在 yield/resume 时被 C 层原子保存/还原 - 误以为
go(function () { ... })是“新开线程”，其实只是在已有 Worker 线程内切出一个新栈帧
hook 函数触发 yield 的真实位置在 C 层 read/write 等封装内部
所有被 hook 的 I/O 函数（如 read, connect, curl_exec）在 C 扩展中已被重定义为 swoole_coroutine_read 等。它们不是简单转发，而是在检测到 fd 不可读/写时，主动调用 co::yield() 的 C 实现 —— 即 sw_coro_yield，此时才真正保存当前栈上下文。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 常见错误：在
go里调用原生file_get_contents，它没被 hook，仍走阻塞系统调用，直接卡死整个 Worker - 必须显式启用 hook：
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL)，否则mysqli、pdo_mysql等扩展中的 socket 调用不会协程化 -
SWOOLE_HOOK_STREAM不覆盖fopen的底层open()系统调用，所以文件读写仍可能阻塞（需配合Co\FileSystem）
协程无法跨 Worker 迁移，栈数据永远绑定到创建它的线程
每个 Worker 进程是单线程模型，其内部所有协程共享同一事件循环（Reactor）和线程栈空间。协程 A 在 Worker 1 中挂起后，绝不可能在 Worker 2 中 resume —— 因为它的寄存器快照、栈内存都只存在于 Worker 1 的地址空间里。
- 这意味着
Swoole\Atomic、static变量、全局数组等，在同一个 Worker 内跨协程是共享的，但不同 Worker 之间完全隔离 - 试图用
pcntl_fork在协程中 fork 子进程会失败，因 fork 后子进程不继承父进程的协程调度器状态 - 协程 ID（cid）只是当前 Worker 内的自增序号，不同 Worker 可能出现重复 cid，不能作为全局唯一标识
真正难调试的点在于：栈切换发生在 C 层，gdb 断点打在 PHP 函数里看不到 yield/resume 的瞬间；strace 也捕获不到，因为根本没进内核态。定位卡顿得靠 swoole_server->stats() 查协程数突增、结合日志里 co::sleep 或 chan->pop 的耗时埋点，再回溯到具体哪一行 hook 函数没生效。
