最稳做法是进「软件商店」→ 找到 Nginx →「设置」→「配置修改」，在 http { 块开头插入含 gzip_vary on 和显式 gzip_types 的完整配置段，避免被站点配置覆盖。
怎么看是前端资源加载慢，还是后端响应慢
直接打开浏览器开发者工具（F12）→ Network 标签页，刷新页面，观察每个请求的「Timing」分段：TTFB（Time to First Byte）高，说明后端处理慢；Content Download 长，但 TTFB 短，大概率是前端资源体积大或没压缩。
常见误判点：TTFB 超过 800ms 就该怀疑 PHP 执行、数据库查询或未启用 fastcgi_cache；若大量 JS/CSS 的「Size」列显示「transferred」远大于「resource」（比如 300KB → 80KB），说明 Gzip 没生效。
- Chrome/Firefox 的 Timing 图里，灰色「Stalled」或「DNS Lookup」/「Connecting」时间长，优先查 CDN、DNS 或 HTTPS 握手问题，不是宝塔配置范畴
- PHP 页面（如
/index.php）TTFB 高，但静态文件（/static/app.js）TTFB 低 → 后端瓶颈，别白忙配 Gzip - 所有文本类资源（
.js、.css、.html）TTFB 正常，但下载耗时久 → 立刻验证 Gzip 是否开启
宝塔里开 Gzip 的三种方式，哪种真管用
宝塔面板有三个入口能“开 Gzip”，但效果和生效范围完全不同：网站设置里的开关只写入站点配置的 server 块，对子路径或代理请求可能失效；软件管理里改 Nginx 主配置才真正全局生效；而「GZIP 压缩」选项卡（新版面板）看似方便，实际只是调用前两者，且不校验 gzip_types 是否覆盖 application/json 这类现代接口必需类型。
- 最稳做法：进「软件商店」→ 找到 Nginx →「设置」→「配置修改」，在
http {块开头插入完整段（含gzip_vary on和显式gzip_types），避免被站点配置覆盖 - 别信「已启用」绿标——它只检查配置文件里有没有
gzip on，不验证语法或生效逻辑 - Apache 用户必须用
.htaccess或主配置启mod_deflate，宝塔的「GZIP 压缩」开关对 Apache 无效
为什么开了 Gzip，Network 里还是没看到 Content-Encoding: gzip
常见原因不是没开，而是配置位置错、类型漏、或被其他规则拦截。Nginx 要求 gzip on 必须在 http 块，不在 server 或 location 里；且 gzip_types 必须显式列出 MIME 类型，光写 gzip on 完全不生效。
- 漏掉
application/json：API 接口返回体不会压缩，尤其 Vue/React 前端直连后端时流量暴增 - 漏掉
image/svg+xml：图标字体、内联 SVG 不压缩，小文件积少成多 - 用了
gzip_comp_level 9：CPU 占用飙升，部分请求直接超时，反而更慢；6 是实测平衡点 - CDN 开了缓存但没透传
Vary: Accept-Encoding：用户拿到的是未压缩版本缓存，本地测试正常，线上失效
缓存头配错比不配还危险
很多人在宝塔「网站 → 设置 → 缓存」里一键开启「静态文件缓存」，结果第二天用户反馈样式错乱、按钮失灵——因为 HTML 和未哈希的 JS/CSS 被强缓存了，更新后根本刷不出来。
- 必须分层：带哈希戳的资源（如
app.a1b2c3.js）可设Cache-Control: max-age=31536000；不带哈希的（app.js）只能用no-cache或max-age=0 - 宝塔生成的缓存规则常把所有
.js统一设expires 1y，要手动进「配置文件」删掉那行，换成带正则匹配哈希的location块 -
Cache-Control: no-cache不等于不缓存，而是强制每次向服务器校验（发If-None-Match），比must-revalidate更稳妥
