file_get_contents 在 swoole 协程中始终阻塞，因其底层依赖同步 read 系统调用，swoole hook（含 swoole_hook_all）默认不接管文件 i/o；需在协程启动前调用 swoole\runtime::enablecoroutine(true) 才能协程化部分文件函数，但推荐直接使用 co::readfile 或 swoole\coroutine\filesystem::readfile 等原生协程 api。
file_get_contents 在 Swoole 协程中依然阻塞，不是配置没开全，而是它压根不支持协程化 —— 无论你开没开 SWOOLE_HOOK_ALL，PHP 原生文件函数都不会被接管。
为什么 SWOOLE_HOOK_ALL 也救不了 file_get_contents
很多人以为开了 SWOOLE_HOOK_ALL 就万事大吉，结果发现 file_get_contents 还是卡住整个协程。原因很直接：
- Swoole 的 Hook 机制对普通文件 I/O（
read()/write()系统调用）默认不接管，哪怕你设了SWOOLE_HOOK_ALL，它也只覆盖 socket、curl、stream 等有限类型 -
file_get_contents底层走的是 libc 的同步 read，不触发 epoll 或 IO 多路复用，协程调度器根本无从“挂起-唤醒” - Hyperf 默认也不自动启用文件 Hook，
Co::set(['enable_coroutine' => true])对它完全无效
哪些文件操作能被协程化（取决于 Swoole 版本）
从 Swoole v4.2.0 开始，运行时可通过 Swoole\Runtime::enableCoroutine(true) 启用文件 Hook，但仅限特定函数，且有隐含前提：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 必须在 协程启动前 调用
Swoole\Runtime::enableCoroutine(true)，放在go()里或控制器中都晚了 - 支持的函数包括：
fopen、fread、fgets、file_get_contents、file_put_contents、unlink、mkdir、rmdir - 底层靠 AIO 线程池模拟协程行为，不是真异步 —— 大量并发小文件读写可能打满线程池，反而拖慢响应
- PHP 8.3+ 中，
file_get_contents还会因内存限制直接崩溃，尤其读 >100MB 文件时
真正安全的协程替代方案
别赌 Hook，直接换掉 file_get_contents。生产环境推荐这三种方式：
- 用
Co::readFile：Swoole 原生协程 API，无需额外配置，返回string，语义最接近，但不支持超时参数（需自己包一层Co::sleep+ 超时判断） - 用流式分块读：
fopen+fread+yieldGenerator，内存可控，兼容所有 PHP 版本，适合处理大文件（如日志分析、哈希计算） - 用
Swoole\Coroutine\FileSystem::readFile（Swoole ≥ 4.8.0）：带超时控制、自动重试、异常明确，比Co::readFile更健壮
最容易被忽略的坑：上下文与错误捕获
就算你换了 Co::readFile，下面这些点仍会导致协程“静默卡死”或数据错乱：
-
Co::readFile抛出的是Swoole\Error，不是Exception，try/catch捕不到，必须用if ($result === false)判断 - 协程内调用
file_get_contents出错后，如果没清理打开的fopen句柄，可能泄漏文件描述符（尤其在 Hyperf 的长生命周期 Worker 中） - Context 不继承子协程 —— 你在主协程里
Context::set('trace_id', 'xxx')，go(function () { ... })里拿不到，得显式传参或用Parallel
