Workerman 4.0.10单进程支撑上万并发依赖非阻塞I/O与事件循环：初始化EventLoop注册fd，epoll/kqueue监听就绪事件；socket强制设为非阻塞；HTTP请求全程异步流转，阻塞调用（如file_get_contents）会导致进程卡死。
要理解Workerman 4.0.10为何能单进程支撑上万并发连接，必须穿透其非阻塞I/O的底层执行逻辑——它不是靠多线程堆资源，而是让每个Worker进程在一次循环中轮询所有活跃连接的读写状态，有事立即处理，无事立刻转向下一个，绝不卡在某次数据库查询或网络等待上。
事件循环如何接管I/O控制权
Workerman启动时，每个Worker进程会初始化一个独立的EventLoop实例，该实例不依赖扩展，纯PHP实现，但默认优先启用libevent或ev扩展（若存在）以获得更高效的epoll/kqueue底层支持。它不会主动调用read()或write()去“等数据”，而是把所有监听socket和已建立连接的fd注册进内核事件表，交由操作系统通知“哪个fd就绪了”。
这一步必须在进程启动早期完成，否则后续所有连接都将降级为select轮询模式，性能断崖式下跌。
当EventLoop开始run()，它就进入一个永不退出的while循环：先调用底层驱动的wait()（如epoll_wait），挂起自身直到至少一个fd触发可读/可写事件；唤醒后批量取出就绪事件，再逐个触发对应connection的onMessage、onClose等回调。
非阻塞模式如何被强制启用
方法一：自动设置
Workerman在socket_create后立即执行stream_set_blocking($socket, false)，对所有监听socket和accept得到的client socket统一设为非阻塞。这是硬性前提，【若手动修改过socket属性并设回阻塞，整个Worker将无法维持高并发】。
方法二：验证是否生效
可在onConnect回调中调用stream_get_meta_data($connection->getSocket())，检查['blocked']字段是否为false；若为true，说明上游代理或自定义代码覆盖了默认行为，必须排查。
一次HTTP请求的非阻塞流转路径
第一步：客户端发来GET /api/user请求 → Workerman的EventLoop检测到该连接fd可读 → 触发onMessage回调。
第二步：框架解析完HTTP头，发现需查数据库 → 不调用PDO::query()，而是调用workerman/mysql提供的asyncQuery() → 此时控制权立刻交还EventLoop，当前连接挂起等待结果，EventLoop继续处理其他fd事件。
第三步：MySQL返回数据包 → EventLoop检测到mysql client socket可读 → 触发预设的异步查询回调 → 将结果组装成HTTP响应 → 调用$connection->send() → EventLoop检测该连接fd可写 → 实际执行write系统调用发送数据。
注意：send()调用本身不阻塞，但若TCP发送缓冲区满，write()会返回EAGAIN，Workerman会自动将待发送数据缓存到connection的outputBuffer，并注册该fd的可写事件，下次循环再试。这个细节决定了它不会因网络慢而拖垮整个进程。
为什么普通file_get_contents会导致阻塞崩溃
直接在onMessage里写file_get_contents('https://api.example.com')，PHP会发起阻塞式curl请求，整个Worker进程卡死在此处，无法响应其他任何连接——EventLoop停转，所有fd事件积压，超时断连雪崩。
正确做法是改用Workerman\Http\Client或workerman/http-client组件，它内部将DNS解析、TCP握手、SSL协商、HTTP收发全部拆解为非阻塞步骤，每一步都注册事件回调，全程不占用EventLoop主线程。
这一步替换不能只改函数名，必须确保所有第三方SDK调用链路都走异步通道，否则任一同步调用都会成为单点阻塞源。
