协程需手动启用Swoole/Swow驱动并替换同步I/O为协程客户端，否则file_get_contents、PDO、curl等仍会阻塞；数据库、Redis、HTTP请求及队列消费均须协程化，否则整体性能受限。
协程不是自动开启的，得手动启用 Swoole 或 Swow 驱动
Webman 默认不启用协程，哪怕你装了 swoole 扩展，file_get_contents、PDO::query 这类同步调用依然会阻塞整个 Worker。必须显式指定协程事件驱动，并确保底层扩展已加载。
检查是否生效：php -m | grep swoole（或 swow），然后在 config/app.php 中设：'event_loop' => 'swoole'（或 'swow'）。别用 ev 或 libevent——它们不支持协程挂起 I/O。
- Ubuntu 下装 Swoole：
pecl install swoole，再往php.ini加extension=swoole - Swow 更轻量，适合高密度调度，但需 PHP ≥ 8.1，安装命令是
pecl install swow - 重启服务后，在
onWorkerStart里打印Workerman\Events\EventInterface::class，确认输出是Workerman\Events\Swoole而非Select
AI 任务不能直接用 curl/guzzle，得用协程客户端
向 OpenAI、Kimi 或本地 LLM 发请求时，若用 guzzlehttp/guzzle 或原生 curl_exec，一次调用就卡死当前协程，100 个并发请求 = 100 个串行等待，彻底废掉协程优势。
必须改用 Swoole 原生协程 HTTP 客户端：Swoole\Coroutine\Http\Client，或封装更友好的 webman-php/openai（专为流式响应设计）。
- 同步调用
file_get_contents('https://api.openai.com/...')→ 直接阻塞，禁止出现在协程上下文 - 正确写法：创建
new Swoole\Coroutine\Http\Client()，调用$client->post()，响应体通过$client->body获取 - 发 100 个 AI 请求？用
go(function () { ... })启 100 个子协程，每个持独立 client 实例 - 流式响应（
stream=true）必须配webman-php/openai，它内置 SSE 解析回调，原生 client 需手动切data:行
数据库/Redis 操作也得协程化，否则成瓶颈
AI 任务常要查用户配额、存生成记录、读提示词模板。如果还用 PDO 或 redis-cli 同步驱动，哪怕协程 HTTP 跑得飞快，一到 DB 就排队等连接，整体吞吐上不去。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
Webman 的协程 MySQL 和 Redis 客户端是 Swoole 提供的，不是简单包装，而是真正复用连接、无锁排队、查询返回数组而非资源句柄。
- 别用
PDO：连接开销大，每次 query 都新建 socket，无法复用 - 改用
Swoole\Coroutine\Mysql：connect 一次后，多个 query 自动复用同一连接，顺序执行不冲突 - Redis 同理：
Swoole\Coroutine\Redis替代phpredis，注意config/queue.php中max_connections要设够（如 300） - 连接池不是默认开启的，需自行封装或引入
webman/mysql插件，配置max_idle_time防连接泄漏
任务分发别卡在主流程，必须走异步队列
用户点“生成 100 集短剧”，控制器里不能循环 100 次 go(...) —— 协程再多，也扛不住内存和事件循环压力。真实生产环境必须解耦：HTTP 请求只负责入队，后续全部由独立 Worker 消费。
Webman 的 redis 队列天然适配协程，但要注意 retry 和失败处理逻辑，否则一个失败任务会拖垮整条队列。
- 入队用
dispatch(new GenerateVideoJob($params))->onConnection('redis')，不要handle()同步执行 -
GenerateVideoJob::handle()内部必须用协程 HTTP/MySQL/Redis，否则消费进程照样阻塞 - 失败必须
throw $e，不能return或静默 log，否则retry_times不生效 - 单个 job 可覆盖重试次数：
dispatch($job)->tries(3)，比全局config/queue.php更灵活
协程能力不是加个扩展就自动生效的，从事件驱动选择、I/O 客户端替换，到队列分发粒度，每层都可能断链。最容易被忽略的是：数据库和 Redis 操作仍用同步驱动，结果 HTTP 层看着并发很高，实际全卡在 MySQL connect 上。
