Swoole HTTP Server启动后请求直接500，主因是配置与行为不匹配：默认禁用静态文件服务，未在onRequest中显式end响应或捕获异常即静默500；PHP错误报告关闭导致异常无日志；协程内误用原生curl、task_worker崩溃或回调注册时机错误亦常见。
为什么 swoole_http_server 启动后请求直接 500？
常见现象是日志里没报错、curl 返回空响应或 500，但 php -m | grep swoole 显示扩展已加载。根本原因往往不是代码逻辑，而是服务器配置未对齐。
-
swoole的http_server默认不启用enable_static_handler，但开发时习惯把前端资源（index.html、js）放在同一目录，误以为能自动服务 —— 实际上所有非/路由都会 fallback 到onRequest回调，若回调里没做response->end()或抛出未捕获异常，就静默 500 - PHP 错误报告级别影响大：
error_reporting若设为0或关闭display_errors，swoole进程内异常不会打到终端或 error_log，只能靠strace -p $pid或在onRequest开头加error_log("hit");排查 - 注意
worker_num设为 1 时调试最友好；设太高会导致复现不稳定，尤其涉及协程上下文（如go(function() { ... })）时变量生命周期容易误判
go 里调用 curl_init 为什么总超时？
这是高频踩坑点：Swoole 协程环境里不能直接用 PHP 原生 curl，它会阻塞整个协程调度器，表现就是所有请求卡住、top 看 CPU 低但响应延迟飙升。
- 必须改用
Swoole\Coroutine\Http\Client，且注意它的set方法参数和原生 cURL 不同，比如timeout是整数秒（非浮点），ssl_host_name必须显式设置才能走 HTTPS SNI - 别在
go外部提前 new Client 实例并复用 —— 协程客户端不是线程安全的，跨协程使用会引发连接错乱，应每个go内独立创建 - 调试时可临时加
Co::sleep(0.001)强制让出调度权，确认是否真被阻塞；生产环境务必用Co::set(['socket_connect_timeout' => 3])全局兜底
热更新代码后 onReceive 回调突然不触发？
游戏公司常跑 swoole_websocket_server，热更后 WebSocket 连接断开、新消息收不到，但 netstat -an | grep :9501 显示端口还在监听 —— 问题不在连接层，而在回调注册时机。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
swoole的回调函数（onOpen、onMessage、onClose）必须在start之前绑定，如果热更逻辑里重写了$server->on('message', ...)，旧回调会被覆盖，而新闭包可能引用了已销毁的类实例，导致静默失效 - 推荐把所有回调统一注册在
Server初始化阶段，业务逻辑通过call_user_func_array或路由分发，避免热更时触碰on*绑定 - 检查
reload是否真正成功：kill -USR1 $master_pid后看ps aux | grep php的 worker 进程 PID 是否刷新；若没变，说明 reload 被拒绝（常见于有协程未结束或信号被屏蔽）
为什么 task_worker 处理耗时任务后，finish 回调收不到？
典型表现：$server->task($data) 返回 true，但 onFinish 死活不进，task_worker_num 设再大也没用。
- 根本原因是
task_worker进程崩溃退出，但主进程没及时感知 —— 常见于 task 里用了不兼容协程的扩展（如redis同步客户端）、或exit()/die()被误调用 -
onFinish只在worker进程中执行，若你把onFinish逻辑写在task_worker里，它永远不会运行 - 务必开启
task_enable_coroutine => true（Swoole 4.5+ 默认 false），否则 task 进程内无法使用Co\MySQL等协程 API，一用就崩
协程上下文隔离比想象中严格：Co::getContext() 和 Co::getPcid() 这类调试辅助函数，只有在真正协程内调用才有效；在 onWorkerStart 这种非协程回调里打印，返回的永远是空或 0 —— 这个细节，面试时很少人当场反应过来。
