file_get_contents 在 hyperf 中会彻底阻塞协程调度器，导致 worker 进程卡死、qps 断崖下跌；必须改用 hyperf\httpclient\client 等协程客户端，禁用 runtimehook 修复，且严禁在 http 请求中调用。
file_get_contents 在 Hyperf 中不是“慢”，是**彻底阻塞协程调度器**。它会把整个 Swoole Worker 进程卡死，导致后续所有请求排队等待，QPS 断崖式下跌——这不是性能问题，是架构误用。
为什么file_get_contents在Hyperf里会卡住整个Worker
Hyperf 基于 Swoole 协程运行，所有 I/O 操作必须是非阻塞的。但 file_get_contents 是 PHP 原生同步函数，底层调用的是 blocking socket，不感知协程上下文。哪怕只调用一次，也会让当前协程挂起、Worker 空转、CPU 占满（常见 top 显示 100%）、其他协程完全无法调度。
这不是 timeout 设置能解决的——超时只是让它“晚点失败”，而阻塞本身已经破坏了协程模型。
- 即使配了
stream_context_create(['http' => ['timeout' => 1]])，仍会阻塞 Worker 直到超时或返回 - PHP 的
allow_url_fopen开启与否，不影响阻塞本质，只影响能否执行 - 开启
RuntimeHook（如Swoole\Runtime::enableCoroutine(true)）对file_get_contents无效：它仅对部分系统调用（如fread,stream_select）做透明协程化，不覆盖 HTTP 请求层
别碰RuntimeHook，直接换协程HTTP客户端
Hyperf 自带 Hyperf\HttpClient\Client，基于 Swoole 协程 HTTP 客户端封装，天然非阻塞、可复用连接池、支持超时/重试/并发控制。这是唯一推荐路径。
- 不要试图用
RuntimeHook“魔改”file_get_contents—— 文档明确说明它不支持 HTTP 流，实测也无效 - 避免自己封装
cURL+Co::sleep模拟异步：cURL 默认仍是同步阻塞，除非显式启用CURLOPT_NOSIGNAL和curl_multi，但那样已脱离协程语义，且难维护 - 确认已安装
swoole扩展并启用http_client：运行php --ri swoole查看是否含http_client => enabled
示例用法：
$client = $this->container->get(\Hyperf\HttpClient\Client::class);
try {
$response = $client->get('https://api.example.com/data', [
'timeout' => 3.0,
'retry' => 2,
]);
return $response->getBody()->getContents();
} catch (\Throwable $e) {
// 记录错误，考虑降级或返回缓存
}
如果必须用file_get_contents（极少数调试/离线场景）
仅限非 Web 请求上下文，比如命令行脚本、定时任务中调用外部 API 且无并发要求。此时需强制隔离：用 Co::exec 启动子进程，或改用 Process 组件，确保不污染主协程环境。
- 绝对禁止在 HTTP 请求生命周期内（如 Controller、Service 方法中）直接调用
file_get_contents - 若强行开启
RuntimeHook并发现file_get_contents偶尔“变快”，大概率是 DNS 缓存或网络抖动带来的错觉，不可靠 - 真正耗时长的点往往不是传输本身，而是 SSL 握手（尤其自签名证书）或远程服务端处理延迟；协程客户端能暴露真实瓶颈（如
time_starttransfer高），而file_get_contents只给你一个黑盒总耗时
协程不是语法糖，是执行模型切换。用同步函数跑在协程框架里，就像在高铁轨道上骑自行车——路是对的，但轮子根本不匹配。
