HTTP服务器启动后收不到请求，需检查worker_num和reactor_num配置是否合理：reactor_num建议设为CPU核心数1–2倍，worker_num推荐cpu_count×2起步，避免设为1导致假死；同时确认端口LISTEN状态并用curl测试。
HTTP服务器启动后收不到请求？检查 set 中的 worker_num 和 reactor_num
默认配置下 Swoole HTTP 服务可能“看起来启动了”，但 curl 或浏览器打不进去，常见原因是工作进程或事件循环线程数不合理。Swoole 不是 PHP-FPM，它靠 reactor 线程收包、worker 进程处理，两者失衡会导致连接被丢弃或响应延迟。
实操建议：
-
reactor_num建议设为 CPU 核心数的 1–2 倍（如 4 核机器设4或8），太小会积压 TCP 连接； -
worker_num推荐从cpu_count * 2起步（如 4 核配8），但若业务含阻塞 IO（如未协程化的 MySQL 查询），需配合max_coroutine控制并发上限； - 切忌把
worker_num设成1来“调试”——单 worker 下一旦某个请求卡住（比如 file_get_contents 同步调用），整个服务就假死； - 启动后用
netstat -ant | grep :8080确认端口处于LISTEN状态，再用curl -v http://127.0.0.1:8080测试，避免只看php server.php是否输出“started”。
为什么 $_GET / $_POST 是空的？别直接依赖超全局变量
Swoole HTTP 服务器不经过 PHP-FPM 的 CGI 生命周期，$_GET、$_POST、$_SERVER 等不会自动填充。你看到的是空数组，不是 bug，是设计使然。
实操建议：
- 从
$request->get、$request->post、$request->server中取值，这是唯一可靠方式； -
$request->rawContent()用于读取原始 body（如 JSON、XML），注意它只可调用一次，多次调用返回空字符串； - 上传文件需用
$request->files，且必须在set中开启http_compression关闭（某些版本压缩会影响文件解析）； - 不要在
onRequest回调外缓存$request对象——它生命周期仅限本次请求，跨协程或异步回调中引用会出错。
高频请求下内存持续上涨？警惕未释放的协程资源
协程不是免费的。高频请求场景下，如果每个请求都 new 一个 PDO、Redis 或 HttpClient 实例却不复用，内存会线性增长，最终 OOM。Swoole 的协程调度器不会自动回收这些对象。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
实操建议：
- 数据库连接务必用连接池（如
swoole/co+spiral/database）或长连接 +go+defer显式 close； - HTTP 客户端优先用
Swoole\Coroutine\Http\Client，创建后记得调用$client->close()，或用defer包裹； - 避免在协程中使用
sleep()、usleep()，改用co::sleep()，否则会阻塞整个 worker； - 用
memory_get_usage(true)在关键位置打点，配合Server->stats()观察connection_num与task_worker_num是否异常升高——这往往是协程泄漏的信号。
WebSocket 和 HTTP 共存时路由混乱？onRequest 和 onMessage 不混用
一个 Swoole Server 实例不能同时以 HTTP 模式和 WebSocket 模式响应同一端口的请求。很多人误以为加个判断就能“自动切换”，结果要么 WebSocket 握手失败（返回 HTML），要么 HTTP 请求被当成帧数据解析报错。
实操建议：
- HTTP 和 WebSocket 必须分离端口，或用反向代理（Nginx）根据
Upgrade: websocket头分发； - 若坚持单端口，得在
onRequest中手动解析$request->header['upgrade'] === 'websocket'，然后调用$server->push()发送握手响应——但这绕过了 Swoole 内置 WebSocket 服务逻辑，无法触发onOpen/onMessage； - 真正共存的正确姿势：启动两个
Swoole\Http\Server实例（不同端口），或用Swoole\WebSocket\Server并在onRequest中处理非 WebSocket 请求（此时它兼容 HTTP，但需自行构造响应）； - 注意
onRequest回调里不能调用$server->start()或任何阻塞式方法，否则整个事件循环卡死。
最常被忽略的一点：Swoole 的 reload 不会重载所有配置项，比如 worker_num 变更必须 kill -USR1 才生效，而 set 中的 max_request 是控制 worker 自动重启的阈值，不是“每 N 次请求就清理内存”的银弹——它只是换进程，不解决协程内对象泄漏。
