进阶必看 Swoole Hook 技术原理面试深度解析

Co::set() 的 hook_flags 必须在 Co::run() 回调开头、所有 go() 前调用，否则因上下文错误报 Invalid argument；它仅作用于当前协程树，不全局生效。

Co::set() 的 hook_flags 必须在 Co::run() 内部、且所有 go() 之前调用，否则直接报错或 Hook 失效——这不是配置问题，是执行上下文错了。

为什么 Co::set(['hook_flags' => SWOOLE_HOOK_ALL]) 一运行就报 Invalid argument？

错误不是出在 flag 值上，而是调用位置。Swoole 的钩子设置是协程局部行为，Co::set() 只能在已进入协程上下文后生效。主进程（即 Co::run() 外）调用它，底层直接拒绝。

• ✅ 正确位置：在 Co::run() 回调函数最开头，早于任何 go()
• ❌ 错误位置：文件顶部、go() 回调内部、onRequest 回调里单独调用
• ⚠️ 注意：Co::set() 不是全局开关，它只影响当前协程及其后续派生的子协程；但因为 Co::run() 是协程调度入口，所以“在它里面最早设一次”就覆盖了整条协程树

SWOOLE_HOOK_TCP 和 SWOOLE_HOOK_CURL 为什么不能互相替代？

它们劫持的是完全不同的函数调用链：前者针对 PHP 流层（stream_socket_client()、fsockopen()、file_get_contents('http://')），后者专攻 libcurl 绑定的 curl_exec()。Guzzle 默认走流，所以开 SWOOLE_HOOK_TCP 就够；原生 cURL 必须显式加 SWOOLE_HOOK_CURL，否则整个 Worker 会被阻塞。

• HTTP URL 的 file_get_contents() → 归 SWOOLE_HOOK_TCP 管
• 本地路径的 file_get_contents('/tmp/a.txt') → 必须开 SWOOLE_HOOK_FILE
• 混合场景（既发 HTTP 又读本地日志）→ 需同时启用 SWOOLE_HOOK_TCP | SWOOLE_HOOK_FILE
• 生产推荐：显式写 SWOOLE_HOOK_ALL | SWOOLE_HOOK_CURL，避免漏掉 cURL

如何快速验证 Hook 是否真正生效？

别只看代码有没有报错，要测行为。最简单有效的方式是并发 sleep：启动两个 go()，各自调用 swoole_timer_sleep(1)（注意不是 sleep(1)，后者会阻塞进程），观察总耗时。

• ✅ 总耗时 ≈ 1 秒 → 协程化成功，sleep 已被 Hook 成非阻塞挂起
• ❌ 总耗时 ≈ 2 秒 → Hook 未生效，可能原因：调用时机错、flag 漏配、或用了未被 Hook 的函数（如 PDO::query()）
• ? 补充验证：用 strace -p $(pidof php) 观察是否还有 nanosleep 系统调用；有则说明仍有阻塞点

哪些函数 Swoole 根本钩不住？

Hook 本质是指针替换，只覆盖它明确注册的函数列表。像 PDO::query()、mysqli::query() 这类数据库操作，虽然底层也走 socket，但绕过了 PHP 流层，Swoole 默认不处理。它们不会自动协程化，必须依赖适配了协程的客户端（如 swoole_mysql 或 Hyperf 的协程 PDO）。

• ❌ 原生 MySQLi / PDO → 同步阻塞，会卡住整个 Worker
• ✅ swoole_mysql 扩展 / HyperfCoroutineMySQL → 底层用协程 socket，与 Hook 机制无关，但效果等价
• ⚠️ 特别注意：exec()、shell_exec()、proc_open() 等进程创建函数，Swoole 不 Hook，也不建议在协程中直接调用

真正容易被忽略的点在于：Hook 不是魔法开关，它只作用于特定函数调用路径；一旦业务逻辑绕过这些路径（比如直连 socket、用扩展自定义 I/O），那协程调度就无从介入。判断一个函数是否被 Hook，最可靠的方式不是查文档，而是看它底层是否最终落入 Swoole 注册的函数指针表——这需要你对 PHP 扩展机制和 Swoole 的 ext-src/swoole_runtime.cc 实现有基本认知。