php中fsockopen默认阻塞，需连接后调用stream_set_blocking($fp, false)设为非阻塞；dns超时问题须改用stream_socket_client配合stream_client_async_connect；多连接并发依赖stream_select轮询或swoole/workerman等协程框架。
PHP 的 fsockopen 默认就是阻塞的，怎么改成非阻塞？
PHP 本身没有原生的“非阻塞 IO”运行时（不像 Node.js 或 Go），所谓非阻塞 IO 在 PHP 中本质是**手动控制 socket 状态 + 轮询或事件驱动**。直接调用 fsockopen 得到的是阻塞 socket，必须显式设置：
$fp = fsockopen('api.example.com', 80, $errno, $errstr, 5); stream_set_blocking($fp, false); // 关键：关闭阻塞否则后续 fread/fwrite 会卡住。注意：stream_set_blocking 必须在连接建立后、读写前调用；如果连接本身超时（比如 DNS 解析慢），fsockopen 仍会阻塞——这时得用 stream_socket_client 配合 STREAM_CLIENT_ASYNC_CONNECT。
用 stream_select 实现多连接并发轮询
stream_select 是 PHP 做非阻塞 IO 的核心函数，它能同时监听多个 socket 的可读/可写状态，避免逐个 fread 卡死。
- 必须把所有待监控的 socket 放进
$read/$write数组，传给stream_select - 调用后数组会被**原地修改**，只保留就绪的 socket，其他被清空——别忘了每次循环前重填
- 超时参数设为
0就是纯轮询（CPU 飙高），设为NULL会无限等待，生产环境建议设为0.1秒左右 - 对 http 请求，要自己处理响应头解析和分块接收，
fgets可能只读到部分数据，得用stream_get_contents或循环fread直到feof或长度满足
Swoole 和 Workerman 哪个更适合高并发非阻塞场景？
纯原生 PHP 模拟非阻塞 IO 效率低、易出错，实际项目几乎都选协程框架：
-
Swoole：C 扩展，性能更高，内置协程、异步 mysql/redis 客户端，CoHttpClient开箱即用，但要求编译安装，linux/macos 友好，windows 支持弱 -
Workerman：纯 PHP 实现，跨平台好，启动快，适合中小型服务或已有代码快速接入，但异步能力依赖pcntl和Event扩展，高并发下内存占用略高 - 两者都不支持同步阻塞函数（如
sleep、file_get_contents），协程内必须用对应异步版本（如Cosleep、CoHttpClient）
选型关键看团队熟悉度和部署环境：有运维能力且追求极致性能，选 Swoole；需要 Windows 兼容或快速 MVP，Workerman 更稳妥。
为什么用了非阻塞还是卡顿？常见漏掉的点
非阻塞不等于高性能，很多问题藏在细节里：
- 数据库操作没换异步驱动：哪怕 HTTP 请求非阻塞了，
mysqli_query仍是阻塞的，必须换成SwooleCoroutineMysql或WorkermanLibAsyncMysql - 文件操作没避开：
file_get_contents、json_decode大文件、正则回溯爆炸，都会让协程“假死”，要用Co::readFile或流式解析 - 错误没捕获：
stream_select返回false表示系统错误（如 fd 超限），0表示超时，不区分会导致逻辑中断 - 连接池没配：高频请求下反复
new CoHttpClient创建销毁开销大，必须复用连接池实例
真正压测时，瓶颈往往不在 IO 层，而在 CPU 密集操作或锁竞争——非阻塞只是第一步，后面还得做协程安全的共享状态管理。