swoole协程调度器通过cpu寄存器快照、按需分配的协程栈和epoll事件循环联动实现纳秒级上下文切换：创建时分配8kb虚拟栈并保存rsp/rip等寄存器；挂起时yield保存现场并等待i/o就绪；恢复时由事件循环查表唤醒、jump_fcontext跳转执行，全程用户态，耗时仅18ns。
要真正理解 Swoole 协程调度器如何在底层驱动 PHP 实现高并发，不能只看 go() 调用后发生了什么，而必须深入到 CPU 寄存器保存、栈空间分配、事件循环触发点这三层物理执行层面——它不是抽象的“切换”，而是精确到纳秒级的上下文跳转与 epoll 就绪通知联动。
协程创建时的栈与上下文初始化
调用 go(function () { ... }) 的瞬间，Swoole 不是简单地起一个线程，而是执行以下动作：
① 从内存池中分配一块 【默认 8KB、按需增长的虚拟内存页】 作为该协程专属栈空间，不立即申请物理内存，避免浪费；
② 构造 coroutine_t 控制块，填入函数指针、参数地址、栈顶指针（stack + stack_size）、初始状态 SW_CORO_INIT；
③ 调用 make_fcontext()（基于 boost.context 汇编实现），将当前 CPU 的 RSP（栈指针）、RIP（指令指针）等 16 个通用寄存器快照保存进 ctx 字段，并把新栈顶地址写入 RSP，为后续 jump_fcontext 做准备；
④ 将该协程加入全局就绪队列 coroutine_queue，但此时它还不会立即运行——必须等到事件循环下一次 tick 才被调度。
协程让出控制权的真实路径
协程不会因 CPU 时间片耗尽被强制中断，它的暂停永远发生在 I/O 等待点或显式 yield。以 Co::get('https://api.example.com') 为例：
方法一：自动 Hook 触发挂起
当启用 Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_TCP) 后，stream_socket_client 调用会被拦截 → 底层改用非阻塞 socket → connect() 立即返回 EINPROGRESS → Swoole 将该 socket 加入 epoll 监听可写事件 → 调用 Coroutine::yield() → 保存当前寄存器现场 → 切回调度器主循环；
方法二：手动让权
直接调用 Co::sleep(0.1)：内部向定时器模块注册一个 100ms 后触发的回调 → 立即执行 yield() → 当前协程状态设为 SW_CORO_WAITING → 控制权交还给 current->origin（通常是主线程调度协程）；
【注意：usleep(100000) 不会触发 yield，它直接陷入 nanosleep 系统调用，整个 Worker 进程卡死】
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
事件循环如何唤醒挂起的协程
epoll_wait 返回后，调度器遍历就绪事件列表：
→ 对每个就绪 socket，查找其绑定的协程 ID（通过 fd 映射表）；
→ 将该协程状态改为 SW_CORO_READY，并移入就绪队列尾部；
→ 若当前无正在运行的协程，或当前协程已主动 yield，则从就绪队列头部取出下一个协程；
→ 调用 Coroutine::resume()：将 origin->ctx（调度器现场）压入寄存器 → jump_fcontext(&origin->ctx, target->ctx, 0, true) → CPU 指令指针跳转回该协程上次 yield 处的下一条指令继续执行；
这个过程全程在用户态完成，没有系统调用开销，切换耗时稳定在 【18ns（Swoole 5.0）】 级别。
协程退出与资源回收时机
协程函数执行完毕（或抛出未捕获异常）后：
→ 状态变为 SW_CORO_END；
→ 栈内存不会立即释放，而是归还至协程内存池，供后续新协程复用；
→ 控制块对象被标记为可回收，但实际销毁延迟到下一次垃圾回收周期（由 swTimer_callback 定时扫描）；
→ 若协程内使用了 defer 函数，会在协程退出前按注册逆序执行所有 defer 回调。
