Swoole安装后无法使用CoHttpClient

先说个很多人踩过的坑：如果你还在用 CoHttpClient，那很可能已经被 Swoole 直接“请出局”了。

CoHttpClient 类不存在？先确认 Swoole 版本和扩展加载状态

并不是代码写错了——CoHttpClient 在 Swoole v5.0+ 已正式被移除，这个类早在 v4.8.0 被标记为废弃，到 v5.0 彻底下线。你现在看到的“类不存在”，八成是升级到了新版 Swoole，但代码还照着旧文档写。

验证方式？跑一下 php --ri swoole，看看输出里的 version 行；再检查有没有 coroutine => enabled 和 http_client => enabled——后者在 v4.8+ 后被拆成独立模块，默认不会开启。

• v4.8.x：正确的类名是 SwooleCoroutineHttpClient，不是 CoHttpClient（Co 这个别名从 v4.6+ 就开始被弃用了）
• v5.0+：必须使用 SwooleCoroutineHttpClient，并且编译时要确认启用了 --enable-http-client
• 如果 php --ri swoole 的输出里找不到 http_client 这一项，那就说明扩展模块压根没加载——光靠一个 enableCoroutine() 是解决不了的

SwooleCoroutineHttpClient 初始化失败的常见原因

就算类名写对了，new SwooleCoroutineHttpClient() 也可能返回 false 或者偷偷失败，问题大多出在协程上下文缺失，或者 DNS 配置不合规。

• 实例必须在 Coun() 内部或 go() 启动的协程中创建；在 onRequest 回调里 new 是可以的，但如果在 onWorkerStart 里 new，因为没有协程环境，一定会失败
• 默认情况下协程 DNS 解析是关闭的，所以 localhost 或域名容易卡在 gethostbyname() 上；需要显式设置 ['enable_coroutine_dns' => true]，或者干脆直接用 IP 地址绕过
• 如果目标地址是 https://，但没配 ssl_host_name，那么 SNI 握手阶段可能会静默挂起。这件事在调用云服务（比如阿里云 OSS）时非常容易踩到

替代方案：不用 Client 类也能发 HTTP 请求？

如果实在不想折腾 SwooleCoroutineHttpClient 的配置，其实还有两个更轻量的路子：

• file_get_contents('http://...') 在协程场景下能用，但仅限于 http:// 和 https:// 协议；一旦 URL 变成 file:/// 或 php://，它会立刻降级为同步阻塞，并且连个警告都不给你
• 也可以考虑第三方协程 HTTP 库，比如 YurunHttp 或 hyperf/http-client。它们在底层会自动适配 SwooleCoroutineHttpClient，对外暴露的接口类似 Guzzle，对 SDK 的兼容性也更好——比如阿里云 OSS SDK v2.4+ 已经原生支持协程了

最后检查：SSL/TLS 握手失败时没有报错怎么办

一种很隐蔽的现象：$client->get() 一直没返回，swoole_get_last_error() 是空的，CPU 占用也不高——这基本可以锁定是 TLS 握手卡住了。

• 先用命令行验证服务端是否正常：openssl s_client -connect api.example.com:443 -servername api.example.com，检查输出有没有 Verify return code: 0 (ok)
• 客户端侧必须设置 ['ssl_host_name' => 'api.example.com']，否则 SNI 扩展不会发送，某些 CDN 或网关会直接拒绝连接
• 如果是私有 CA 证书，不要设置 ssl_verify_peer => true，应该改用 ssl_cafile 指向你的根证书路径。注意：路径必须是绝对路径，因为在 daemon 模式下相对路径会失效

有一个最容易被忽略的点：v5.0+ 的 SwooleCoroutineHttpClient 默认启用的是 TLS 1.3，但一些老设备（比如部分 Android WebView）并不支持这个版本，需要手动降级——加上 set(['tls_version' => 'TLSv1.2']) 就行。