swoole_http_server是swoole_server的子类，继承全部底层能力但屏蔽onconnect/onreceive，仅暴露onrequest高层事件；它对http协议支持“够用但不完整”，生产环境必须前置nginx代理。
swoole_server 和 swoole_http_server 的本质关系
swoole_http_server 是 swoole_server 的子类，不是并列关系。它继承了全部底层能力（如多进程管理、Reactor/Worker 模型、task/tick/finish 等 API），但屏蔽了 onConnect/onReceive 这类原始 TCP 层回调，转而暴露 onRequest —— 一个已解析 HTTP 报文的高层事件。
这意味着：你不能在 swoole_http_server 实例上调用 onReceive，但可以照常调用 task()、tick()、addProcess()；它底层仍是 TCP Server，只是帮你把 HTTP 解析这层封装掉了。
为什么不能直接用 swoole_http_server 对外提供 Web 服务
它对 HTTP 协议的支持是“够用但不完整”：不支持 HTTP/2（Swoole 5.0+ 才开始实验性支持）、不处理 chunked transfer encoding 的流式 body、不校验或重写某些 header（如 Content-Length 冲突时行为未定义）、不自动处理 CONNECT 隧道等。
真实生产环境必须前置 Nginx，常见配置要点包括：
-
proxy_http_version 1.1：启用长连接，避免频繁建连 -
proxy_set_header Connection "keep-alive"：透传连接状态 -
proxy_set_header X-Real-IP $remote_addr：补全客户端真实 IP（否则$request->server['remote_addr']总是127.0.0.1） - 务必加
if (!-e $request_filename) { proxy_pass ... }，让 Nginx 先尝试静态文件，再 fallback 到 Swoole
Swoole\Http\Server 和 swoole_http_server 哪个该用
看 PHP 扩展版本：Swoole 4.0+ 必须用 Swoole\Http\Server（命名空间风格），旧版（2.x）只能用 swoole_http_server（函数式风格）。两者功能一致，但方法名大小写不同：on('start') 通用，但 set() 在旧版是 set()，新版是 set()（同名），真正差异在对象初始化和命名空间加载上。
如果你用的是 Composer 安装的 swoole/extension 或 PECL 安装的 5.x 版本，swoole_http_server 已被废弃，调用会触发 E_DEPRECATED 警告，且可能在 6.0 中彻底移除。
什么时候该退回去用 swoole_server 自己拼 HTTP
极少数场景下需要精细控制 HTTP 流程，比如：
- 实现自定义协议网关（HTTP + 私有 header 校验）
- 做流式响应（SSE 或分块传输）且
$response->write()不满足时，需自己构造响应头+body 分段 send - 对接不标准的下游设备（如某些 IoT 设备发的 malformed HTTP 请求）
- 调试协议层问题，比如想看到原始
onReceive数据流，而不是被解析后的$request->get
这时你得手动拼 HTTP 响应报文（状态行 + headers + 空行 + body），还要注意 Content-Length 计算、字符编码、CRLF 换行 —— 这些 swoole_http_server 已帮你做了，退回 swoole_server 就是主动接下这些细节负担。
