必须重新编译swoole.so并启用--enable-swoole-curl，运行时调用Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_NATIVE_CURL)，且需在协程上下文中执行curl_exec()，三者缺一不可。
必须重新编译 swoole.so，仅靠 PHP 代码或配置无法开启原生 cURL 协程支持。
编译时必须加 --enable-swoole-curl
这个开关决定 cURL hook 的底层能力是否被编译进扩展二进制。漏掉它，后续所有 curl_exec() 调用都会 fallback 到同步阻塞行为，甚至卡死协程调度器。
- configure 命令必须包含：
./configure --with-php-config=/path/to/php-config --enable-swoole-curl - 系统需提前安装 libcurl 开发包：macOS 上运行
brew install curl；Ubuntu 是sudo apt install libcurl4-openssl-dev；CentOS/RHEL 是sudo yum install libcurl-devel - configure 不报错但静默跳过 cURL 支持的情况很常见——只要找不到
curl/curl.h，它就直接忽略--enable-swoole-curl
运行时必须调用 Runtime::enableCoroutine() 并启用 SWOOLE_HOOK_NATIVE_CURL
编译支持只是前提，运行时还需显式启用 hook 才能让 curl_exec() 进入协程调度流程。
Test Curl 2
下载
父母的功课——育儿心理学对话支持技能（心虫增强版）。提供结构化对话、情绪识别、场景匹配与安全检测；可选Python脚本（scripts/）在SKILL_DIR/data/本地存储评估历史、洞察与会话状态，不对外传输。核心路径：觉察（看见防御）→接纳（慈悲是……
- 推荐写法：
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_NATIVE_CURL) - 不要只传
true，那会启用全部 hook（包括不必要或有风险的），明确指定 flag 更安全可控 - 该调用应在程序入口（如 server 启动前）执行一次，全局生效；运行中切换可能引发状态混乱
- 注意：Swoole 5.0+ 已将
SWOOLE_HOOK_NATIVE_CURL标记为 legacy，但目前仍可用；新项目应优先评估Swoole\Coroutine\Http\Client
SwooleCurlHandler 不等于协程化，容易误判
很多用户以为用了 SwooleCurlHandler 就“协程了”，其实它只是兼容层封装，底层仍走 libcurl 同步逻辑，极易退化为阻塞。
- 它依赖
SWOOLE_HOOK_NATIVE_CURL且必须在已启用 hook 的协程上下文中调用，否则就是普通 cURL - 不处理协程 DNS（仍用同步
gethostbyname），不自动管理Expect或Content-Length头，易触发服务端异常 - Guzzle 默认
CurlHandler会绕过 Swoole hook，直接调 libcURL —— 此时Runtime::enableCoroutine()完全无效 - 验证是否真协程化：不能只看有没有报错，要观察并发请求是否真正并行、响应时间是否不随请求数线性增长
最常被忽略的一点：即使编译和运行时都配对了，只要在非协程环境（比如 FPM 模式下、或没用 Co\run() / go() 包裹的代码里）调用 curl_exec()，它照样阻塞。协程化不是开关，是执行上下文 + 编译能力 + 运行时 hook 三者缺一不可。
