Swoole 4性能优化核心在于协程全量启用与IO协程化、worker/task进程数合理配比、连接池与多级缓存应用；编译参数仅需按需调整，生产环境优先使用宝塔或PECL安装稳定版。
Swoole 4 的性能优化不是靠堆参数，而是围绕协程、进程模型和IO调度做系统性调优。编译参数影响的是底层能力支持，而运行时配置决定实际并发表现。关键不在“怎么编译”，而在“编译后怎么用”。
协程必须全量启用，且IO操作全部协程化
协程是Swoole 4性能的基石。只要有一个阻塞IO（比如原生mysqli、file_get_contents、curl_exec）混入协程环境，整个worker就可能卡死。
- 所有网络IO必须使用Swoole协程客户端：
Swoole\Coroutine\MySQL、Swoole\Coroutine\Redis、Swoole\Coroutine\Http\Client - 文件读写改用
Swoole\Coroutine\FileSystem或异步方式，避免fopen/file_put_contents直连磁盘 - 启动时强制开启协程：在
Server构造前调用Swoole\Runtime::enableCoroutine(true)，确保全局协程拦截生效
worker_num与task_worker_num要按CPU和业务类型配比
这两个参数不是越大越好，错误设置反而引发上下文切换风暴或任务积压。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
worker_num建议设为CPU物理核心数的1～2倍（如8核服务器设6～12），超配会导致频繁进程切换，吞吐不升反降 -
task_worker_num设为worker_num的1/3～1/2，专用于50ms以上耗时逻辑（如发邮件、写日志归档、调第三方API） - 务必在
onTask中调用$server->finish($result)，否则响应永远无法返回客户端
连接池与缓存策略决定读性能上限
高并发读瓶颈往往不在Swoole本身，而在下游依赖的响应延迟。
- MySQL/Redis必须使用连接池（如Hyperf的
Pool组件或Swoole原生ConnectionPool），避免每次请求新建连接 - 热点数据加多级缓存：本地用
Swoole\Table存会话状态或配置项；分布式用Redis集群，设置合理过期与穿透保护 - 数据库查询必须有索引覆盖+读写分离，避免单点慢查拖垮整个worker
编译参数只在必要时调整，生产环境优先用稳定版扩展
除非你明确需要某项底层特性（如TLS 1.3支持、zlib压缩开关），否则不建议手动编译。宝塔面板或PECL安装的Swoole 4.10+已默认启用绝大多数优化选项。
- 常用编译选项仅限开发调试：
--enable-openssl（HTTPS支持）、--enable-http2（HTTP/2服务）、--enable-sqlite3（嵌入式DB支持） - 禁用无用模块可略微减小内存占用：
--disable-debug（关调试符号）、--disable-jemalloc（用系统malloc） - 生产环境强烈推荐通过宝塔「软件商店」一键安装，版本兼容性与依赖自动处理更可靠
