协程服务器与异步服务器是两种根本不同的并发模型：前者依赖自动挂起/恢复调度，后者依赖手动事件回调；协程服务器必须显式启用enable_coroutine（如runtime::enablecoroutine()或server->set(['enable_coroutine' => true])），否则recv()/send()仍阻塞，协程客户端调用会卡死worker；异步服务器中禁止直接使用协程api，否则报错；协程高并发易压垮下游，须用连接池和限流机制防控。
协程服务器不是“更高级的异步服务器”，而是两种根本不同的并发模型：一个靠自动调度挂起/恢复，一个靠手动注册回调驱动。选错会导致代码难维护、性能反降、甚至连接堆积。
协程服务器必须启用 enable_coroutine 才生效
很多人以为只要用了 Swoole\Coroutine\Server 就是协程模式，其实不是。Swoole 4.4+ 默认关闭协程 Hook，recv() 和 send() 仍会阻塞——除非显式调用 Runtime::enableCoroutine() 或在 Server->set() 中开启 enable_coroutine。
-
enable_coroutine => true是硬性开关，不设等于退化为同步阻塞行为 - 若同时使用
Co\MySQL等协程客户端，但没开 Hook，connect()会卡死整个 Worker - PHP 8.1+ 可配合
SWOOLE_HOOK_ALL，但要注意curl、file_get_contents等函数需确认是否被 Hook 到
异步服务器的 onReceive 回调里不能直接调用协程 API
异步 TCP 服务器（swoole_server）运行在事件循环中，所有回调都在主线程内执行。此时调用 Co\Redis::connect() 或 Co\MySQL::query() 会抛出致命错误：Fatal error: Uncaught Swoole\Error: must be called in the coroutine。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 异步模式下只能用传统阻塞 API（如
mysqli），或投递到task进程处理 - 混用
$server->task()+onTask是安全路径，但要小心task_worker_num配置过小导致任务排队 - 试图在
onReceive里go(function(){...})不解决问题：协程无法嵌套启动在非协程上下文中
协程服务器高并发时容易压垮下游服务
协程轻量，1 个 Worker 能跑上万协程，但它们共享底层资源：MySQL 连接池、Redis 连接数、HTTP 客户端并发限制。没有节流机制时，并发请求会瞬间打满数据库连接或触发限流。
- 比如 MySQL 协程客户端默认不限制连接数，1000 个并发协程可能尝试建 1000 个连接，而 mysqld max_connections=200 → 大量连接失败
- 解决办法不是关协程，而是用
Swoole\Coroutine\Pool管理连接，或配置max_idle_time、max_active - 协程里调用第三方 HTTP 接口（如 OpenAI），务必加
Channel限流或熔断，否则上游一抖动，本地协程全卡在recv()
真正难的从来不是“怎么写协程”，而是“协程里该等谁、等多久、等不到怎么办”。异步靠回调把问题摊开给你看，协程则把等待藏在同步语法下面——藏得越深，出问题时越难定位。
