Webman 默认不启用 Gzip 压缩，需由 Nginx/Apache 在反向代理层统一处理；PHP 层用 ob_gzhandler 无效且危险，因其响应通过 Response 对象直写 socket，绕过 PHP 输出缓冲，强行启用会导致双重压缩或空响应。
Webman 默认不启用 Gzip 压缩，必须由 Nginx 或 Apache 在反向代理层统一处理；PHP 层用 ob_gzhandler 不仅无效，还可能引发双重压缩或空响应。
为什么 Webman 里加 ob_start('ob_gzhandler') 没用
Webman 是基于 Workerman 的常驻内存型框架，所有响应都通过 Response 对象直接写入 socket，完全绕过 PHP 的传统输出缓冲机制。调用 ob_start('ob_gzhandler') 不会生效——它只对 echo/print 类同步输出起作用，而 Webman 的响应是异步构造、批量发送的。
更危险的是：如果 Nginx 已开启 gzip（宝塔默认开启），再在 Webman 中强行注册 ob_gzhandler，会导致响应头出现 Content-Encoding: gzip, gzip，浏览器解压失败，页面白屏或乱码。
- Webman 启动日志里看不到
Using epoll？先确认event扩展已装且启用 - 检查
config/server.php中'worker_num'是否设为物理核数（非逻辑线程数） - 确保没在中间件或控制器里调用
ob_start—— 它对 Webman 无意义，纯属干扰
Nginx 配置必须包含 application/x-httpd-php
Webman 返回的 HTML/JSON 响应，HTTP Content-Type 是 text/html 或 application/json，但 PHP-FPM 动态生成的内容在 Nginx 视角下属于 application/x-httpd-php 类型。若 gzip_types 里漏掉它，Nginx 就不会对 Webman 的响应体压缩。
立即学习“PHP免费学习笔记（深入）”；
宝塔面板【GZIP 压缩】选项卡默认勾选类型里通常不含 application/x-httpd-php，需手动补上；若直接编辑配置文件，务必确保这一项在列表中：
gzip_types text/plain text/css application/javascript application/json text/xml application/xml application/xhtml+xml text/javascript application/x-httpd-php;
- 改完后执行
nginx -t验证语法，再nginx -s reload - 用
curl -H "Accept-Encoding: gzip" -I http://your-domain.com/api/test检查返回头是否有Content-Encoding: gzip - 注意：SVG、字体等资源若也走 Webman 路由（如
/static/icon.svg），需额外加入image/svg+xml到gzip_types
静态资源坚决交给 Nginx 托管
Webman 处理静态文件（CSS/JS/图片）是重大性能浪费：每个请求都要进 PHP 进程、解析路由、构造 Response，完全丧失 Nginx 的零拷贝和 sendfile 优势。
正确做法是在 Nginx 配置中用 location 显式拦截静态路径，跳过 PHP-FPM：
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
try_files $uri =404;
}- 确保该
location块在location ~ \.php$之前，避免被 PHP 路由劫持 - Webman 的
public/目录需映射为 Nginx 的root，不要用alias，否则路径拼接易出错 - 开发时可临时用 Webman 提供的
Static中间件调试，上线前必须移除
真正关键的点就三个：别碰 ob_gzhandler、Nginx gzip_types 补全 PHP 类型、静态文件彻底剥离 Webman。其他“压缩 HTML 字符串”“合并 JS”之类操作，在 Webman 场景下收益极低，还增加维护负担。
