Hyperf 3.1协程调度基于Swoole用户态调度器，单Worker内无系统调用切换；事件循环通过epoll/kqueue接管I/O，协程挂起后由事件就绪唤醒；每个HTTP请求绑定独立协程，DI容器与上下文严格隔离，确保生命周期安全。
面试官问Hyperf3.1协程调度原理与事件循环底层机制，你需要说清Swoole协程如何在PHP进程内实现非阻塞调度、事件循环如何接管I/O等待、以及Hyperf如何基于此构建请求生命周期——不能只背“挂起恢复”四个字。
协程调度器不是线程调度器
Hyperf3.1的协程调度器由Swoole内核提供，它不依赖操作系统线程切换，而是在单个PHP Worker进程中用用户态栈保存/恢复执行上下文。当你调用Co::sleep(1)或Co\Http\Client->get()时，当前协程的执行状态（包括局部变量、调用栈、寄存器快照）被压入协程栈并标记为suspended，调度器立即切出，让出CPU给其他就绪协程。
这一步的关键在于：【协程切换全程不触发系统调用，无上下文切换开销】。如果误以为协程调度等同于pthread_yield()，就会在压测时发现QPS卡在3000以下——因为实际瓶颈是内核态切换成本，而非业务逻辑。
事件循环如何接管I/O等待
Hyperf3.1启动时，Swoole会初始化一个基于epoll（Linux）或kqueue（macOS）的事件循环，所有协程发起的I/O操作（如MySQL查询、HTTP请求、文件读写）都被注册进该循环。当协程调用Co\Mysql::query()时，Swoole将socket fd加入epoll监听列表，并立即将该协程挂起；此时事件循环继续轮询其他fd，一旦目标数据库返回数据，epoll触发可读事件，调度器唤醒对应协程并恢复其执行。
注意：若你在协程中混用file_get_contents()这类同步函数，事件循环无法拦截其系统调用，整个Worker进程会被阻塞——【Hyperf3.1要求所有I/O必须走Swoole协程API】。
Hyperf请求生命周期与协程绑定
第一步：Swoole收到HTTP请求后，为每个请求创建独立协程，执行Hyperf的HttpServer中间件链。
第二步：中间件执行过程中，遇到yield $this->redis->get('key')，协程挂起，事件循环接管Redis连接的读写事件。
第三步：Redis响应到达，Swoole将结果注入协程上下文，恢复执行至return new Response(...)，响应发出后协程自动销毁。
这个过程里，协程ID与请求ID严格一对一绑定，Hyperf通过ApplicationContext::setContainer()为每个协程隔离DI容器实例——避免静态变量跨请求污染。若忘记在onClose回调中清理static $cache = []，内存泄漏会在第500次请求后开始明显增长。
