协程挂起是保存寄存器、栈指针等执行现场至协程结构体并置为suspended状态，恢复则由事件循环驱动还原上下文后从中断处继续执行。
协程挂起与恢复不是靠操作系统调度，而是 Swoole 在用户态用寄存器+栈指针快照实现的上下文切换。
协程挂起时到底发生了什么
协程挂起不是“暂停线程”，而是保存当前执行现场：包括 CPU 寄存器（如 RIP、RSP）、栈顶指针、局部变量所在栈帧位置。这个快照被存入协程结构体中，然后协程状态设为 SUSPENDED，并加入对应 I/O 事件等待队列（比如 epoll 的读就绪队列）。
常见触发挂起的场景有：
- 调用被 hook 的阻塞函数，如
mysql_query、curl_exec、sleep、co::sleep - 显式让出控制权，如
co::yield()或channel->pop()阻塞等待 - 协程内发生未捕获异常且未设置错误处理器
注意：file_get_contents 默认不被 hook，除非显式启用 swoole.enable_coroutine=1 并确保 PHP 版本 ≥ 8.1；否则它会直接阻塞整个进程。
协程恢复的关键是事件循环驱动
恢复动作由 Swoole 的事件循环（Reactor）发起，不是协程自己“醒过来”。当底层 epoll_wait 返回某 socket 可读/可写时，调度器从完成队列取出对应协程，把之前保存的寄存器和栈指针全部还原，CPU 就像从未中断过一样继续执行下一条指令。
这导致几个关键事实：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 恢复后代码从挂起点的下一行开始执行，不是重放整个函数
- 协程栈空间是独立分配的（默认 2MB 栈上限，但实际初始仅 2KB~8KB），不会和主线程栈混用
- 如果挂起期间对应的资源（如 MySQL 连接）已断开或超时，恢复后可能抛出
Swoole\Coroutine\Exception，而非静默失败
为什么 co::sleep(1) 不阻塞其他协程
因为 co::sleep 底层不是调用系统 usleep，而是注册一个定时器到事件循环，并将当前协程置为 TIMEOUT 状态挂起。此时调度器立刻切走，去运行其他就绪协程。1 秒后事件循环触发定时器回调，把该协程重新标记为就绪并放入调度队列。
对比之下，sleep(1) 是同步系统调用，会阻塞整个 Worker 进程 —— 这在协程环境里是绝对禁止的。
容易忽略的一点：co::sleep 的精度受事件循环 tick 间隔影响，默认是 10ms，所以 co::sleep(0.001) 实际约等于 10ms，不是微秒级唤醒。
调试协程挂起/恢复问题的实用手段
协程卡死、假死、无法恢复，多数源于挂起后没人唤醒，或恢复时栈已损坏。排查优先看这几处：
- 是否在协程中用了未被 hook 的阻塞函数（如原生
fsockopen、stream_socket_client） - 连接池是否耗尽，导致
pool->get()挂起后一直等不到空闲连接 - 协程内抛了异常但没被
try/catch捕获，导致协程提前退出而未归还资源 - 使用了非协程安全的扩展（如某些老版本
pdo_mysql），造成内部锁死
加日志最有效的方式是在关键路径插入 Co::getuid() 和 debug_backtrace()，确认挂起前后是否为同一协程 ID，以及栈帧是否连续。
