协程调度依赖epoll/kqueue等i/o多路复用机制，并非自动异步；file_get_contents默认仍阻塞，须经swoole runtime::enablecoroutine() hook拦截才转为协程安全；co::sleep通过定时器+yield让权，usleep则同步阻塞导致进程卡死。
协程调度依赖 epoll/kqueue，不是“自动变异步”
协程本身不改变 IO 行为，file_get_contents 还是阻塞的，除非被 Swoole hook 拦截或显式替换。Swoole 的异步非阻塞 IO 实际由两层支撑：底层用 epoll（Linux）或 kqueue（macOS/BSD）做事件多路复用，上层靠协程在事件就绪时恢复执行。没有就绪通知，协程就挂起；没人注册监听，IO 就永远等不到唤醒。
常见错误现象：
- 在 CLI 脚本里调用
Co::readFile后直接exit，文件没读完就退出 —— 因为事件循环没运行，epoll_wait根本没开始监听 - 对普通文件（如
/tmp/log.txt）调用Co::readFile，性能反而更差 ——epoll对 regular file 不生效，Swoole 会退化为线程池模拟异步，增加上下文切换开销
Co::sleep 和 usleep 的区别本质是“是否进事件循环”
Co::sleep(1) 是协程安全的等待：它向定时器模块注册一个 1 秒后触发的事件，然后立刻 yield，把控制权交还给调度器；而 usleep(1000000) 是纯同步系统调用，直接进入内核 nanosleep，期间不返回、不触发任何事件，整个 Worker 进程卡死。
使用场景：
- 需要让出 CPU 给其他协程处理请求时，必须用
Co::sleep - 调试中临时加延时，误用
sleep()或usleep()会导致整个服务假死，尤其在onRequest回调里 -
Co::sleep(0)可用于强制让出当前时间片，类似 Go 的runtime.Gosched()
Swoole\Runtime::enableCoroutine() 不是万能开关
启用后，Swoole 会尝试 hook 常见的 PHP I/O 函数（如 fread、stream_socket_client），但无法拦截所有路径。比如某些 C 扩展绕过 PHP 流层直连 libc（如部分 Redis 扩展的 redis->get），或使用 proc_open 启动子进程，这些仍会阻塞。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
参数差异与风险：
-
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL)hook 范围最大，但初始化更慢，且可能破坏某些依赖阻塞行为的旧代码 - 生产环境建议按需启用，例如只开
SWOOLE_HOOK_TCP+SWOOLE_HOOK_SSL，避免影响file类操作 - 开启后仍要检查实际调用链 ——
var_dump(stream_get_wrappers())可确认php://等流是否已被重写
协程间共享全局变量，但 IO 状态不共享
每个协程有独立栈和寄存器状态，但 $_SERVER、$GLOBALS、静态属性、单例对象仍是进程级共享。这意味着你在协程 A 里改了 Config::$timeout = 5，协程 B 下次读到的就是 5 —— 不是线程安全的。
容易踩的坑：
- 在
onRequest中修改超全局数组（如$_GET['token'] = decrypt(...)），后续协程可能读到污染值 - 用
Co::getContext()存请求上下文，但忘记在 defer 中清理，导致内存泄漏 - 以为用了协程就“天然隔离”，结果数据库连接复用逻辑出错，多个协程共用一个未 reset 的
MySQLi实例
最常被忽略的一点：协程调度器只在 IO 就绪或定时器触发时才有机会切回，如果你的代码全是 for ($i=0; $i 这类纯计算，调度器完全插不进手 —— 它不会主动中断 CPU 密集型逻辑，必须靠 <code>Co::yield() 或触发 IO 才能让出。
