协程切换实际发生在swoole的c层，由汇编指令直接操作寄存器和栈指针完成，不依赖php的yield或zend vm，全程在用户态微秒级完成。
协程切换不是靠 PHP 的 yield 或 Generator 实现的，而是由 Swoole C 层用汇编指令直接操作寄存器和栈指针完成——这点在面试中答错，基本等于没碰过底层。
协程切换实际发生在哪一层？
Swoole 协程调度完全绕开 PHP 引擎的执行器（Zend VM），也不依赖 setjmp/longjmp 这类通用跳转。它在 x86_64 下使用 mov %rsp, [rdi] 和 mov [rdi], %rsp 等原生汇编指令保存/恢复栈顶，配合 mov %rbp, [rsi] 等操作寄存器上下文。整个过程在微秒级内完成，且不触发系统调用。
- PHP 层调用
go()或Co\run()时，C 层分配一块独立栈（默认 2MB，可配coroutine.stack_size）并注册切换钩子 - 真正挂起发生在 hook 函数内部，比如
socket_connect被拦截后，先保存当前协程栈帧，再跳转到调度器 - 恢复时不是“重跑函数”，而是把 CPU 寄存器设回挂起点前一刻的状态，接着从下一条指令继续执行
为什么不能用 yield 模拟协程切换？
yield 是 PHP 层语法糖，本质是生成器对象状态机，每次 next() 都要经过 Zend VM 的 opcode 解析、变量表查找、堆栈帧重建——这和 Swoole 的寄存器级快切有数量级差异。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
yield无法跨函数边界保存 C 层调用栈（比如mysql_real_query的本地栈帧） - 它不感知 I/O 事件，必须靠外部轮询或
sleep(0)主动让出，无法做到“IO 就绪即唤醒” - 所有
yield-based 协程库（如 Amp）在 PHP 8.1+ 后都已转向 Swoole Runtime Hook 模式，而非自研调度
Swoole\Runtime::enableCoroutine() 做了什么？
这个函数不是“开启协程支持”，而是批量替换 libc 函数符号地址，把 connect、read、write、gethostbyname 等 30+ 系统调用指向 Swoole 自己的 hook 版本。
- 未启用时，
file_get_contents("http://api.com")会阻塞整个 Worker 进程 - 启用后，该调用被重定向为非阻塞 socket + epoll_wait，期间协程自动挂起
- 注意：
SWOOLE_HOOK_ALL会覆盖更多函数（包括curl_exec），但部分扩展（如 Redis 扩展）需单独启用SWOOLE_HOOK_REDIS - 常见翻车点：
opcache.enable_cli=1会导致 hook 失效，因为 OPcache 缓存了原始函数符号绑定
协程栈和全局变量共用意味着什么？
每个协程有独立栈空间，但所有协程共享同一份进程内存空间——所以 static $x、global $y、$GLOBALS 全部是跨协程可见的。这不是 bug，是设计使然。
- 静态变量在 Worker 生命周期内持续存在，两次请求间不会重置（对比 FPM 每次新建进程）
- 若在协程里往
static $cache写入大数组，且未手动unset，就会累积成内存泄漏 - 协程退出时只回收其栈内存，不清理任何全局作用域变量，这点和线程完全不同
- 真正危险的是“隐式共享”：比如一个协程改了
$_SERVER['REQUEST_TIME']，另一个协程读到的就是脏值
汇编级切换听起来很硬核，但对业务开发者来说，关键不是看懂 push %rbp，而是理解“挂起即寄存器快照”“恢复即上下文还原”这两个动作带来的确定性——它决定了你写的同步代码，为何能精准回到 IO 后那一行，而不是从头开始或跳到别处。
