Swoole扩展本身不会导致PHP性能下降，反而专为提升高并发性能而设计；但错误使用（如未协程化阻塞函数、滥用全局变量、xdebug冲突、连接池泄漏、worker_num配置失当）会引发协程阻塞、内存泄漏、状态污染等问题，最终导致性能劣化或服务崩溃。
swoole 扩展本身不会导致 PHP 性能下降；相反，它专为提升高并发场景下的性能而设计。但错误使用或配置不当，反而会引发内存泄漏、协程阻塞、状态污染等问题，最终表现为性能劣化甚至服务崩溃。
swoole 启用后变慢的常见原因
-
未关闭调试扩展冲突：
xdebug与swoole不兼容，启用时会导致协程调度异常、CPU 占用飙升，甚至segfault错误 -
全局变量或静态变量滥用：在
onRequest回调中直接修改static $cache或写入$_SESSION，会导致跨请求数据污染，后续请求因读取脏数据而逻辑出错或重试失败 -
阻塞式函数未协程化：比如直接调用
sleep(1)、file_get_contents()、PDO::query()，会挂起整个协程调度器，所有并发请求被串行化 -
连接池未复用或泄漏：每次请求都新建
Redis或MySQL连接，且未调用close()或未归还到连接池，快速耗尽文件描述符（Too many open files） -
Worker 进程数设置不合理：设成
worker_num => 64但机器只有 4 核，上下文切换开销反超收益；或设得太小（如 2），无法充分利用 CPU
如何验证是否真“变慢”而非误判
- 先确认是否真的用了
swoole：运行php --ri swoole，看输出中是否有enabled和version；再检查代码是否实际启动了Swoole\Http\Server或其他 Server 实例 - 对比基准：用
ab -n 1000 -c 100 <a href="https://www.php.cn/link/e0b92938a739b3561d351a5b3f7ed5c4">https://www.php.cn/link/e0b92938a739b3561d351a5b3f7ed5c4</a>测原生php-fpm和swoole的 QPS，不要只看单次响应时间 - 查看资源占用：
top看%CPU是否持续 100%，cat /proc/$(pidof php)/limits | grep "Max open files"看是否接近上限
生产环境必须做的三件事
- 在入口脚本开头加：
Swoole\Runtime::enableCoroutine(true);—— 否则curl_exec、pdo等仍为阻塞行为 - 所有数据库/缓存操作必须用
swoole提供的协程客户端（如Swoole\Coroutine\MySQL）或经连接池封装的实例，禁止裸用PDO - 每个
onRequest回调里避免定义全局函数、静态类属性、或未清理的闭包引用，尤其注意use ($var)捕获大对象（如上传的文件内容）
真正的性能瓶颈往往不出现在 swoole 本身，而在于开发者沿用 FPM 思维写协程代码——把常驻进程当成一次性的脚本跑，结果越优化越慢。
