Amp协程性能瓶颈在于I/O未异步化、连接未复用或混用同步调用；HttpClient比cURL慢主因是未启用连接池、每次新建TCP连接或误用wait()；需显式配置LimitingPool、避免协程内wait、分离CPU与I/O任务、合理设置Redis连接池参数并显式超时。
用 Amp 协程调用服务，性能瓶颈通常不在协程本身，而在 I/O 阻塞点没真正异步化、连接复用被忽略、或错误地混用了同步阻塞调用。
为什么 Amp\Http\Client\HttpClient 调用反而比 cURL 慢？
常见原因是：没启用连接池、每次请求都新建 TCP 连接、或误用了 wait() 强制同步等待。
- 默认的
Amp\Http\Client\HttpClient不自动复用连接；必须显式传入Amp\Http\Client\Connection\LimitingPool实例 - 若在协程中调用
file_get_contents()、curl_exec()或 PDO 同步查询，整个协程会被挂起——Amp 无法调度，等同于退化为同步模型 -
Amp\Promise\wait()在顶层（如 CLI 脚本末尾）是必需的，但绝不能在协程内部反复调用，否则串行化执行
如何让 Amp\Parallel 和 HTTP 协程不互相拖慢？
并行 Worker 和协程 HTTP 客户端属于不同调度域，混用时容易因资源争抢或阻塞调用导致吞吐下降。
- 避免在 Worker 中再发起
Amp\Http\Client请求；Worker 应专注 CPU 密集型任务（如解析、加密），I/O 留给主协程处理 - 若必须跨 Worker 发起网络请求，改用
amphp/byte-stream+ 原生 socket 异步读写，或通过消息队列解耦 - Worker 启动数建议 ≤ CPU 核心数；过多会触发上下文切换开销，反而降低整体吞吐
Amp\Redis\Client 连接池配置的关键参数
Redis 是高频依赖，连接未池化或超时设置不合理，会直接卡住整条协程链。
