Swoole\Runtime::enableCoroutine()必须在Server->start()前调用，否则sleep()、file_get_contents()等仍会阻塞进程；需指定正确flags（如SWOOLE_HOOK_ALL），且不能晚于任何协程创建或函数首次调用。
协程不生效，90% 是 Swoole\Runtime::enableCoroutine() 没调对位置或没覆盖关键函数。 它不是“开了就自动全协程”，而是必须在 Worker 进程启动前、所有协程创建前完成 hook 注册，且要按需指定 flag —— 否则 sleep()、file_get_contents()、curl_exec() 照样阻塞整个进程。
为什么 Swoole\Runtime::enableCoroutine() 必须放在 onWorkerStart 之前
协程 hook 是在 PHP 扩展加载时注册到函数指针表的，一旦某个函数被首次调用（比如 sleep() 在协程里执行），PHP 就会绑定其原始实现。如果此时 hook 还没启用，该函数就永远走同步路径。
-
onWorkerStart是 Worker 进程已启动、PHP 脚本已加载完毕后的回调 —— 此时很多框架初始化代码（如 Laravel 的服务提供者）可能已调用过file_get_contents()或sleep()，hook 已失效 - 正确位置是：Swoole Server 实例化之后、
start()之前，且必须在任何go()或Co\run()之前 - 常见错误写法：
$server->on('workerStart', fn() => Swoole\Runtime::enableCoroutine());—— 太晚了 - 推荐写法：
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL); $server->start();
SWOOLE_HOOK_ALL 并不等于“所有函数都协程化”
它只覆盖 Swoole 自己封装的 libc 系统调用（如 connect()、read()、write()、gethostbyname()），但对第三方扩展中直接调用底层库的函数无效。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 例如
rdkafka扩展的rd_kafka_poll()不会被 hook，协程仍会阻塞 -
PDO构造函数本身不 IO，但$pdo->query()若基于 mysqlnd，需额外开启SWOOLE_HOOK_STREAM才能协程化 -
openssl相关函数（如stream_socket_enable_crypto()）需SWOOLE_HOOK_SSL，否则 TLS 握手阶段卡死 - 验证是否生效：在协程内执行
sleep(1)，同时发起另一个协程请求；若第二个请求延迟 >1s，则 hook 未覆盖成功
协程内 file_get_contents() 仍阻塞？检查三件事
这个函数是高频翻车点，表面看启用了 SWOOLE_HOOK_FILE，但实际仍同步执行。
- 确认启用的是
SWOOLE_HOOK_FILE，不是仅SWOOLE_HOOK_STDIO（后者只管fread()/fwrite()） - 确认 URL 协议：
file_get_contents('http://...')走的是 cURL 或 stream wrapper，需额外加SWOOLE_HOOK_CURL或SWOOLE_HOOK_STREAM - 确认未被框架提前调用：ThinkPHP/Laravel 的自动加载器或配置读取可能在 hook 前就触发了
file_get_contents('xxx.php')，导致函数绑定固化 - 更稳妥方案：直接换用
Swoole\Coroutine\Http\Client或Swoole\Coroutine\FileSystem::readFile()
协程栈和全局变量共享带来的隐性泄漏
协程切换不销毁栈，也不重置全局作用域 —— 这意味着 static 变量、global 数组、未 unset 的大对象都会跨请求累积。
- 典型现象：
static $cache = [];在onRequest中不断$cache[$key] = $bigData;，内存持续上涨 -
$_SERVER、$_GET等超全局变量在协程间共享，若某次请求写入了自定义键，下次请求可能意外读到 - 解决思路：避免在协程内使用
static缓存；必须用时，确保在协程退出前unset()或清空；敏感上下文建议用Co\Channel显式传递 - 调试技巧：用
swoole_memory_dump()或gc_collect_cycles()+memory_get_usage()定位泄漏源头
真正难的不是记全所有 hook flag，而是理解每个 flag 对应的函数表边界，以及它们在真实调用链中的实际触发点。一个 file_get_contents('https://...') 可能横跨 SWOOLE_HOOK_FILE、SWOOLE_HOOK_SSL、SWOOLE_HOOK_CURL 三层，漏一层，就退化为同步阻塞。
