Swoole 4 不原生支持 Brotli 压缩，因其仅内置 gzip 和 deflate，无 brotli 相关配置、函数或编译开关；br 响应头实际来自 Nginx 反向代理压缩或 PHP 层手动调用 brotli_compress() 并设头，推荐交由 Nginx 或 CDN 统一处理以保障兼容性与性能。
Swoole 4 本身不提供或参与 HTTP 响应体的 Brotli 压缩（如 content-encoding: br），它也不编译或集成 ngx_brotli 模块——那是 Nginx 的扩展，与 Swoole 无关。
为什么 Swoole 不“开启 Brotli 压缩”？
Swoole 是 PHP 的异步协程网络引擎，运行在应用层；它处理 HTTP 请求时，响应压缩逻辑需由开发者自行实现，或依赖 Web 服务器（如 Nginx）完成。Swoole 内置仅支持 gzip 和 deflate，不原生支持 Brotli 编码。官方源码和扩展文档中无 brotli 相关配置项、函数或编译开关。
若你在 Swoole HTTP Server 中看到 br 响应头，实际来源只有两种可能：
- Nginx 作为反向代理前置，已启用 Brotli 并对 Swoole 返回的内容做了动态压缩
- PHP 应用层手动调用
brotli_compress()（需安装brotli扩展）并设置Content-Encoding: br头，但需自行处理客户端协商（Accept-Encoding）、编码兼容性及缓存一致性
想让 Swoole 项目用上 Brotli？推荐路径
不建议在 Swoole 中硬编码 Brotli 压缩逻辑，因为：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- PHP 的
brotli扩展（如pecl install brotli）非标配，且性能弱于 Nginx 的 C 模块 - 缺少自动
Vary: Accept-Encoding、预压缩文件匹配（brotli_static on）、流式压缩等关键能力 - 易引发 Content-Length 错误、分块传输混乱等问题
更可靠的做法是：保留 Swoole 专注业务逻辑，把 Brotli 交给 Nginx 处理：
- 确保 Nginx 已编译
ngx_brotli模块并正确配置brotli on - 将 Swoole 服务设为 Nginx 后端（proxy_pass），所有静态资源和动态响应均由 Nginx 统一压缩
- 若用 CDN，直接开启其 Brotli 支持（Cloudflare、阿里云 CDN 等均默认启用）
附：验证是否生效的关键点
无论压缩由谁执行，最终看浏览器请求响应头：
- 发起请求时带
Accept-Encoding: br,gzip - 响应头含
Content-Encoding: br且Vary: Accept-Encoding - 响应体体积明显小于 gzip 版本（尤其 JS/CSS/HTML）
不要依赖 php -m | grep brotli 或 swoole_version() 查找 Brotli 支持——它不存在于 Swoole 运行时。
