Swoole HTTP服务器启动后收不到请求的主因是未调用start()、监听地址绑定为127.0.0.1导致外部不可达、端口被占用却静默失败，需检查onStart/onRequest日志确认事件循环是否运行。
为什么 swoole_http_server 启动后收不到请求？
常见现象是进程跑起来了，netstat -tlnp | grep :80 也显示监听中，但 curl 或浏览器完全没响应。核心原因通常是事件循环没真正跑起来，或者端口被占用但没报错。
实操建议：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 检查是否漏掉
start()调用 ——swoole_http_server实例化后必须显式调用start()，它不是构造即运行 - 确认监听地址：用
0.0.0.0:9501而非127.0.0.1:9501，否则 Docker 容器外无法访问 - 关掉 Apache/Nginx：Swoole 默认监听 9501，但如果误配成 80 且 Apache 已占，
swoole_http_server不会报错，只会静默失败 - 加日志：在
onStart和onRequest里写file_put_contents('/tmp/swoole.log', ...)，确认回调是否触发
swoole_timer_tick 和 swoole_timer_after 怎么选？
两者都用来定时，但语义和资源消耗差很多。用错会导致内存涨、定时器堆积、甚至进程卡死。
实操建议：
-
swoole_timer_tick是周期性触发，适合心跳、轮询、状态同步等场景；但必须手动调用swoole_timer_clear关闭，否则永远存在 -
swoole_timer_after是单次延迟执行，适合发邮件、清理缓存、异步重试等“一次性的后续动作” - 不要在
onReceive或onRequest里反复创建swoole_timer_tick，每创建一个就多一个常驻定时器，1000 个连接 × 每个建 1 个 tick = 1000 个定时器 - 如果需要“每个连接独立计时”，改用
swoole_timer_after+ 连接 ID 标记，或直接用协程co::sleep
协程 mysql_query 报 MySQL server has gone away 怎么办？
这是 Swoole 协程 MySQL 最典型的问题，不是网络断了，而是连接被服务端主动断开（比如 wait_timeout 到期），而协程客户端没感知、还拿旧连接发包。
实操建议：
- 初始化时设置
connect_timeout和read_timeout，但更关键的是开启mysql->set(['timeout' => 3])配合自动重连 - 所有查询前加
if (!$mysql->connected) { $mysql->connect(); }—— 协程 MySQL 对象不自动重连 - 避免跨协程复用同一个
Swoole\Coroutine\Mysql实例；每个协程应 new 自己的实例，或用连接池管理 - 生产环境务必配置 MySQL 的
wait_timeout=300（而非默认 8 小时），让空闲连接更快释放，减少“假连接”残留
swoole_websocket_server 如何安全广播消息？
直接遍历 $server->connections 广播，看似简单，但容易 crash：连接可能已断开但 ID 还在数组里，push 会抛异常；并发推送还可能触发 writev 错误。
实操建议：
- 用
isEstablished($fd)兜底判断：只有$server->isEstablished($fd) && $server->exist($fd)同时为 true 才推送 - 别在
onMessage里同步遍历所有连接 —— 改用go(function () use ($server, $data) { ... })异步处理，避免阻塞事件循环 - 大消息（>64KB）先
gzip压缩再发，否则 WebSocket 分片逻辑可能出错；小消息也建议设websocket_compression => true在配置里 - 广播前检查
$server->connection_info($fd)的websocket_status，值为 3 表示已握手完成，状态为 0 或 2 的连接不能发文本帧
