当Swoole应用在生产环境响应变慢、吞吐量骤降、协程挂起后无法恢复，或者首次请求延迟过高时，请勿盲目重启或随意调整参数。必须立即定位阻塞点，切断瓶颈链路，这才是解决Swoole性能问题的正确姿势。
确认是否真正启用协程
第一步不是修改配置，而是确认代码是否运行在协程上下文中。在请求入口处添加：var_dump(SwooleCoroutine::getPcid());，若输出为false或0，说明当前执行并未处于协程模式——后续所有I/O操作（包括数据库、Redis、HTTP请求）都将以同步阻塞方式运行，Worker进程会立即卡死。
常见陷阱有哪些？使用SwooleHttpServer但忘记开启协程模式，或已开启但入口函数未被go()包裹；又或者引入了第三方SDK，例如Laravel Octane默认未开启协程MySQL，底层仍使用PDO同步驱动。
修复方法很简单：确保服务启动时设置'enable_coroutine' => true，并且所有耗时I/O调用均需在协程内执行，示例如下：go(function () { $mysql = new SwooleCoroutineMySQL(); $mysql->connect([...]); });。
精准定位慢请求的真实源头
不要仅依赖日志中的“超时”信息，必须抓取完整调用栈才能找到问题根因。
方法一：启用Swoole内置慢日志。在$server->set()中添加：'slowlog' => '/tmp/swoole.slow.log', 'timeout' => 0.5（单位秒）。该配置仅对协程内的I/O操作生效，超过0.5秒未返回的协程将被记录堆栈，包含文件名、行号、协程ID及阻塞函数名。
方法二：强制触发全链路追踪。在关键入口插入：SwooleCoroutine::defer(function () { SwooleDebug::dumpBackTrace(); });，配合strace -p [pid] -e trace=epoll_wait,read,write可确认是否卡在系统调用层。
另外，务必关闭opcache.validate_timestamps选项（设置为0），否则每次文件变更都会触发全量校验，导致协程在require阶段无故挂起数百毫秒，此类问题排查起来非常隐蔽。
优化Worker与Task Worker配比
首先，评估CPU密集型任务占比。若慢请求中超过30%的耗时来自图像缩放、JSON序列化大型数组、正则匹配长文本等纯计算操作，则必须将其剥离到Task Worker中处理。
接着，设置独立的Task进程池：$server->set([ 'task_worker_num' => 4, 'task_tmpdir' => '/dev/shm', 'task_max_request' => 5000 ])。注意task_tmpdir建议使用内存文件系统，以规避磁盘I/O带来的额外开销。
关键点在于，异步投递不应阻塞主流程。在request回调中应调用$server->task($data)而非$server->taskwait()；Task Worker内部绝对禁止使用sleep()、usleep()或任何同步I/O，否则整个Task进程将被锁死。
需要提醒的是，Task Worker数量不宜超过CPU核心数的1.5倍，否则上下文切换开销会反超并行处理带来的收益。
避免在Windows原生环境运行
如果开发机是Windows，且直接运行php server.php，请立即停止这种做法——这并非配置问题，而是架构层面的不可用。
Swoole在Windows下无法使用epoll，只能退化为select模型，协程调度器每毫秒轮询一次fd，单个Worker的并发上限连200都达不到；更严重的是，gethostbyaddr这类DNS解析调用会阻塞整个进程，且没有超时机制。
唯一可行的方案是：启用WSL2，安装Ubuntu 24.04 LTS，PHP和Swoole全部在WSL2内编译安装，数据库和Redis也部署在同一WSL2实例中，host配置固定为127.0.0.1，同时禁用所有自动网卡探测逻辑。
