Swoole HTTP服务器启动后无响应，主因是监听地址设为127.0.0.1导致外部不可访问、端口被占用时静默失败、未启用SWOOLE_BASE模式或防火墙/安全组未放行。
没有“全网最全”的 Swoole 面试图谱，只有真实高频、易被追问、一问就卡壳的点——这些才是你该优先吃透的。
为什么 swoole_http_server 启动后不响应请求？
常见现象是进程起来但 curl 返回空或 connection refused，不是配置写错，而是没注意监听地址和端口是否被占用或绑定失败。
-
swoole_http_server默认只监听127.0.0.1:9501，若从外部访问需显式设为0.0.0.0:9501 - 端口被占用时不会报错，只会静默失败；建议启动前用
lsof -i :9501或netstat -tuln | grep 9501检查 - Linux 上若启用
iptables或ufw，需放行对应端口，否则连本地curl 127.0.0.1:9501都不通 - PHP 版本兼容性：Swoole 5.0+ 要求 PHP ≥ 8.1，低版本 PHP 加载扩展会失败，
php -m | grep swoole看不到模块即属此因
go() 和 defer 在协程中怎么配合才不踩坑？
很多人以为 go() 启动协程后加 defer 就能自动释放资源，其实 defer 是绑定到当前协程栈的，主协程退出后子协程里的 defer 不会触发。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
go(function() { defer { echo "cleanup\n"; }; sleep(1); });—— 这个defer永远不会执行，因为主协程已结束，子协程未被等待 - 正确做法是用
Swoole\Coroutine::wait()显式等待，或在协程内用defer+Co::sleep()控制生命周期 - 数据库连接、Redis 客户端等长连接对象不能跨协程复用，每个
go()内应新建实例，否则可能遇到连接状态错乱或Connection reset
为什么 onReceive 里用 file_get_contents 会阻塞整个 Worker？
这是 Swoole 最典型的同步陷阱：file_get_contents、curl_exec、mysql_connect 等传统 PHP 函数全是同步阻塞的，一旦调用，当前协程卡死，Worker 就无法处理其他请求。
- 必须替换为协程版：用
Swoole\Coroutine\Http\Client替代curl，用Swoole\Coroutine\MySQL替代mysqli - 注意
mysql_query不是协程函数，哪怕在go()里调也照样阻塞；真正协程化的是$mysql->query()（对象方法） - 第三方 SDK（如阿里云 OSS SDK）默认不支持协程，需确认是否提供
AsyncClient或自行封装成Co::socket调用
如何判断一个 Swoole 服务是否真的“热更新”成功？
reload 不等于热更新。Swoole 的 kill -USR1 只会重启 Worker 进程，Manager 和 Master 进程仍在运行，但旧代码可能还残留在内存里。
- 改完代码后，先
kill -USR1 $(cat swoole.pid)，再立刻检查ps aux | grep php—— Worker 进程 PID 应全部变化 - 关键验证点：在新代码里加一行
echo "v2.1 loaded at " . date('H:i:s') . "\n";并观察日志输出时间是否更新 - 如果用了
opcache，需在 reload 前调用opcache_reset()，否则 PHP 文件内容虽变，opcode 缓存仍用旧版 - 常被忽略的是
static属性和global变量，它们不会随 Worker 重启清空，需在onWorkerStart中重置
真正难的从来不是记住 Swoole 有多少 API，而是当 onRequest 延迟飙升、coroutine_count 持续上涨、memory_limit 被突破时，你能快速定位是协程泄漏、连接未关闭，还是 opcache + autoload 导致类重复加载——这些细节藏在日志和 swoole_table 统计里，而不是思维导图上。
