Swoole中Hook各种函数类型的覆盖区别-Swoole-PHP中文网

swoole_hook_tcp仅覆盖fsockopen、stream_socket_client等网络i/o函数，故file_get_contents('http://')协程化而本地文件需swoole_hook_file；curl需单独启用swoole_hook_curl；swoole_hook_sleep影响协程调度，漏配会导致sleep阻塞整个worker；co::set()必须在co::run()内首行调用才生效。

swoole中hook各种函数类型的覆盖区别

SWOOLE_HOOK_TCP 覆盖哪些函数，为什么 file_get_contents('http://') 行但读本地文件不行

SWOOLE_HOOK_TCP 只管走 PHP 流层的网络 I/O，不碰系统文件读写。它劫持的是 fsockopen、stream_socket_client、stream_select、fread（当流来自网络时）、file_get_contents（仅限 http://、https:// 等 URL 协议头）这些函数。

本地路径如 file_get_contents('/tmp/data.json') 走的是 php_stream_open_wrapper 的 file:// handler，底层调用 open() 系统调用，必须由 SWOOLE_HOOK_FILE 覆盖。

SWOOLE_HOOK_TCP 生效时：file_get_contents('https://api.com') → 协程化
SWOOLE_HOOK_FILE 未开时：file_get_contents('/var/log/app.log') → 仍阻塞 Worker
混合场景（既调 API 又读配置文件）需同时启用：SWOOLE_HOOK_TCP | SWOOLE_HOOK_FILE

SWOOLE_HOOK_CURL 和 SWOOLE_HOOK_TCP 不能互相替代

curl_exec 完全不经过 PHP 流层，libcurl 自己封装 socket，所以 SWOOLE_HOOK_TCP 对它完全无效。哪怕你开了 SWOOLE_HOOK_ALL，cURL 也不会被自动 Hook——Swoole 明确把 cURL 拆出来单独管理。

常见误判：用 Guzzle 发请求却只开 SWOOLE_HOOK_TCP，结果发现并发卡死。Guzzle 底层默认用 stream_socket_client，所以它确实能被 SWOOLE_HOOK_TCP 覆盖；但如果你手动切到 cURL handler（比如设 handler => \GuzzleHttp\Handler\CurlHandler::class），就必须加 SWOOLE_HOOK_CURL。

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

原生 curl_init() + curl_exec() → 必须开 SWOOLE_HOOK_CURL
Guzzle 默认 stream handler → SWOOLE_HOOK_TCP 就够
生产建议：显式组合，避免依赖默认行为：SWOOLE_HOOK_ALL | SWOOLE_HOOK_CURL

SWOOLE_HOOK_SLEEP 为什么容易被忽略，但它影响协程调度节奏

sleep(1) 和 usleep(100000) 看似只是“等一下”，但在协程里它们是调度锚点。没开 SWOOLE_HOOK_SLEEP 时，这两个函数会真正让当前 Worker 进程休眠，阻塞所有协程；开了之后，Swoole 把它转成定时器 + 协程挂起，其他协程照常运行。

这个 Hook 不影响性能数字，但决定你能不能写出“可控延迟”的逻辑。比如做重试退避、限频、心跳间隔，如果漏掉它，整个服务在 sleep 期间就失去响应能力。

它覆盖 sleep、usleep、time_nanosleep（PHP 7.3+）
不覆盖 Co::sleep() —— 那是原生协程 API，无需 Hook
和 SWOOLE_HOOK_FILE 类似，它属于“低频但关键”的 Hook，漏了不报错，只在压测或长周期任务里暴露问题

Hook_flags 是协程局部设置，但生效范围是后续所有子协程

Co::set(['hook_flags' => ...]) 必须在 Co::run() 内、且任何 go() 启动前调用。这不是一个全局配置，而是为当前协程设置“子协程默认钩子模板”。一旦进入 go() 回调，再调 Co::set() 就无效，还会直接抛出 Invalid argument: Co::set() must be called in coroutine。

很多人把 Co::set() 放在文件顶部，或者在某个 go() 里单独调用，结果部分协程没被 Hook，导致偶发阻塞。最稳的写法就是：入口进 Co::run()，第一行就设好 flag，后面所有 go() 都继承它。

错误位置：Co::set() 在 Co::run() 外、或在 go(function () { Co::set(...); }) 里
正确位置：Co::run(function () { Co::set([...]); go(...); go(...); });
注意：Co::set() 不会覆盖已存在的子协程，只影响后续新建的协程

验证是否生效最直接的方式：启动两个 go() 并发执行 sleep(1) 或 file_get_contents('http://example.com')，用 microtime(true) 测总耗时。接近 1 秒说明 Hook 成功；接近 2 秒说明至少有一个没被协程化——这时候得回头查 Co::set() 位置和 flag 组合。