Swoole异步IO不依赖PHP原生stream/curl，而是直接接管系统事件循环；Swoole\Async仅限CLI未启Server时使用，Web服务器中须改用协程；Channel适用于协程间通信，Process\Pool适用于进程间长期协作；协程Hook后curl仍慢主因DNS、TLS、超时等配置缺失。
不是所有“异步”都叫 Swoole 异步 IO —— 它不走 PHP 原生 stream 或 curl 的非阻塞封装，而是直接接管系统级事件循环（epoll/kqueue），靠回调或协程驱动。用错地方或混用同步写法，反而会卡死整个进程。
为什么 Swoole\Async::readFile 在 CLI 下能跑，Web 服务器里却报错？
因为 Swoole\Async 系列函数只在 CLI 模式、且未启动 Server（如 Swoole\Http\Server）时可用。一旦你调用了 new Swoole\Http\Server 或 Swoole\WebSocket\Server，Swoole 就进入事件驱动 Server 模式，Swoole\Async 被禁用 —— 此时再调用会直接抛出 Fatal error: Uncaught Swoole\Exception: async io is not available。
- CLI 脚本中做一次性异步文件/HTTP 请求，可用
Swoole\Async::readFile/Swoole\Async::dnsLookup - HTTP/WebSocket Server 中必须改用协程方式：
Swoole\Coroutine::sleep、Co\Runtime::enableCoroutine()+file_get_contents（需开启协程 Hook） - 若强行在 Server 里调用
Swoole\Async，进程不会报错退出，但后续所有请求会 hang 住 —— 这是高频线上事故点
Swoole\Coroutine\Channel 和 Swoole\Process\Pool 都能传数据，该选哪个？
看通信方向和生命周期：Channel 是协程间单向/双向通信，轻量、无锁、纯内存；Process\Pool 是进程间通信，带序列化开销，适合跨进程长期协作。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 同个 Worker 内多个协程协作（比如并发查 DB 后合并结果），用
Channel：创建快、无 syscall、支持超时pop(1.5) - 需要把任务分发给独立子进程处理（如图像压缩、PDF 生成），且希望复用进程避免频繁 fork，用
Process\Pool：自带启动/回收管理，但要注意stdIn/stdOut管道缓冲区满会导致阻塞 - 别在协程里
new Process后直接wait()—— 这会阻塞当前协程，等价于同步调用，失去并发意义
协程 Hook 后 curl_exec 变异步了，但为啥有时还是慢？
Hook 只让阻塞调用变成协程挂起，并不改变网络 RTT 或后端响应时间。真正拖慢的，往往是 DNS 解析、TLS 握手、连接复用没开，或没设超时。
- 确保开启
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL)，否则curl_exec仍是同步阻塞 - DNS 必须用
Co\DNS\Resolver或设置CURLOPT_DNS_CACHE_TIMEOUT，否则每次请求都走系统同步解析 - 务必设置
CURLOPT_CONNECTTIMEOUT_MS和CURLOPT_TIMEOUT_MS，协程不会自动帮你设超时 - 复用
CurlHandle实例（而非每次 new），避免重复 TLS 握手和 TCP 建连开销
协程不是银弹 —— 它解决的是“等待时别闲着”，而不是“让网络变快”。最常被忽略的是：协程上下文切换本身有微小开销，当业务逻辑极轻（比如纯数组计算），开协程反而比直行慢；而真正耗时在 IO 的场景，才值得切。
