ThinkPHP 6 默认不开启 Gzip 压缩，应由 Nginx/Apache 或 Swoole 服务层处理；禁用 PHP 层 ob_gzhandler，配置 Nginx 开启 gzip 并设置 Vary: Accept-Encoding，优化 JSON 输出及响应头以提升缓存与压缩效率。
ThinkPHP 6 如何开启 Gzip 压缩
默认不开启，gzip 压缩必须手动启用，否则响应体全是明文 HTML/JSON，浪费带宽。核心是让 Web 服务器（Nginx/Apache）处理压缩，而不是框架本身——ThinkPHP 没有内置 gzip 编码逻辑，强行在 PHP 层 ob_gzhandler 容易和 Swoole、OpCache 冲突。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Nginx 配置中确认已启用
gzip on，且gzip_types包含text/html、application/json、text/css、application/javascript - 避免在 ThinkPHP 的中间件或控制器里调用
ob_start('ob_gzhandler')，这会导致 Content-Length 错误、缓存失效、Swoole 下直接报错 - 若用 Swoole 运行，需在
swoole_http_server初始化时设置'http_compression' => true，而非依赖 PHP 输出控制
如何确保响应头不干扰 CDN 或浏览器缓存
ThinkPHP 默认会写入 X-Powered-By: ThinkPHP 和 Content-Encoding: gzip（如果 Nginx 压缩了），但某些 CDN 会因 Set-Cookie 或 Vary: Accept-Encoding 缺失而降级缓存策略。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 删除敏感响应头：在全局中间件中调用
header_remove('X-Powered-By')和header_remove('X-Frame-Options')（如不需要） - 显式声明
Vary: Accept-Encoding：Nginx 中加add_header Vary "Accept-Encoding";，否则 CDN 可能对 gzip/non-gzip 请求返回同一份缓存 - 静态资源（CSS/JS）务必配置
Cache-Control: public, max-age=31536000，ThinkPHP 路由生成的 URL 不带版本号时，靠这个保命
JSON 接口响应体积过大？检查 json_encode 选项
ThinkPHP 的 json() 方法底层调用 json_encode()，默认不压缩空格、不跳过空字段，导致 JSON 体积多出 15%～30%。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 全局统一使用
JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_COMPACT：在基础控制器的success()方法里封装json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_COMPACT) - 避免在数组中传入
null值再靠前端判断，ThinkPHP 不会自动过滤；改用array_filter($data, function($v) { return $v !== null; })预处理 - 大数组分页接口，禁用
toArray()全量转换，改用toCollection()->only(['id', 'title'])显式指定字段
为什么开了 Gzip，Chrome Network 面板仍显示 “transferred” 和 “resource” 大小一样
这不是 ThinkPHP 的问题，而是 Chrome 显示逻辑：它只显示解压后的内容长度（resource），而 transferred 是实际传输字节数。如果两者相等，说明压缩没生效——大概率是 Nginx 没配对，或请求头没带 Accept-Encoding: gzip。
排查步骤：
- curl 测试：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/api/list，看响应头是否有Content-Encoding: gzip - 检查 Nginx 日志是否记录
gzip_ratio，或临时加add_header X-Gzip-Ratio $gzip_ratio;辅助验证 - 注意：POST 请求、带 Cookie 的请求、部分移动端 WebView 可能不发
Accept-Encoding，此时压缩天然失效，不能只测 curl GET
真正影响带宽的是传输字节数，不是页面上那个“resource”数字。别被 Chrome 的 UI 带偏了。
