启用 gzip_static on 可让 Nginx 直接返回预生成的 .gz 文件，零 CPU 开销；需提前用 gzip -k 生成同名压缩文件，精简 gzip_types 仅保留文本类型，配合 proxy_cache_key 和 gzip_vary on 隔离缓存，再用 gzip_disable 屏蔽低效 UA。
直接用 gzip_static on，让 Nginx 跳过实时压缩，优先返回已存在的 .gz 文件——这是避免二次计算最干净、零 CPU 开销的方式。
启用预压缩文件自动匹配
Nginx 不会自己去压缩文件，但能智能识别并直接提供预生成的压缩版本。前提是：你提前用 gzip -k 为每个文本资源生成同名 .gz 文件（如 style.css → style.css.gz），且确保它们在同一目录下。
- 在
http或server块中添加：gzip_static on; - 无需开启
gzip on，也无需设置gzip_comp_level——这些对预压缩路径完全不生效 - 浏览器请求带
Accept-Encoding: gzip时，Nginx 自动 304 或 200 返回.gz文件，并带上Content-Encoding: gzip
精简 gzip_types，排除已压缩格式
即使启用了 gzip_static，如果 gzip_types 错误地包含图片、字体等类型，Nginx 在 fallback 到动态压缩时仍可能尝试压缩它们，造成无效计算。
- 只保留真正受益的文本类型：
text/plain text/css application/javascript application/json text/xml application/xml image/svg+xml - 明确剔除：
image/jpeg image/png image/webp font/woff2 application/octet-stream等——它们本身已是高压缩率格式，再压无收益反增开销 - 注意：SVG 属于文本格式，可压缩；而 WOFF2 字体已是压缩格式，不应再进 gzip 流程
配合缓存键隔离不同编码版本
若同时提供未压缩和 .gz 版本，必须确保它们被缓存为独立条目，否则容易发生缓存污染（比如非 gzip 请求命中了 gzip 缓存）。
- 在
proxy_cache_key中显式包含$http_accept_encoding：proxy_cache_key "$scheme$request_method$host$uri$is_args$arg_v$http_accept_encoding"; - 这样，
Accept-Encoding: gzip和空值的请求会被分别缓存，互不干扰 - 搭配
gzip_vary on，确保响应头带Vary: Accept-Encoding，让中间 CDN 或代理也按此区分缓存
关闭低效客户端的动态压缩兜底
老旧浏览器（如 IE6）不支持 .gz 文件或解析有缺陷，Nginx 默认可能退回到动态压缩——这既无必要又浪费 CPU。
- 用
gzip_disable "MSIE [1-6]\.";直接禁用这类 UA 的压缩能力 - 它们将收到原始未压缩内容，跳过所有 gzip 处理环节，包括预压缩匹配和动态压缩
- 现代边缘节点几乎不需兼容此类 UA，该配置可进一步收窄压缩执行面
