直接启用gzip_static on并确保预压缩.gz文件存在且与原始文件mtime一致，是提升静态资源加载效率的核心；它不压缩只查找同名.gz文件，绕过cpu开销，需在静态资源location中精准配置，与gzip共存作兜底。

直接启用 gzip_static on 并确保预压缩文件存在且时间戳一致，是提升静态资源下发效率的核心。它不压缩、不计算，只查找并返回已有的 .gz 文件，从而绕过 CPU 压缩开销，让 JS、CSS、JSON 等文本类资源加载更快。

构建阶段必须生成同名 .gz 文件

Webpack 或 Vite 构建时需显式添加压缩插件，不能依赖 Nginx 动态压缩：

• Webpack 用户用 compression-webpack-plugin，设置 deleteOriginalAssets: false（保留原始文件）
• Vite 用户配 vite-plugin-compression，ext: 'gz'，threshold 建议 ≥1024 字节
• 关键要求：每个 .js、.css、.json 文件旁必须有对应 .gz 文件，如 main.a1b2.js → main.a1b2.js.gz
• HTML 文件一般不预压缩；若强制压缩，需确保 Nginx 权限可读且未被 try_files 规则干扰

Nginx 配置要精准匹配静态资源路径

gzip_static 不受 gzip_types 控制，但只在 location 匹配范围内生效：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 不要在全局 http 块或 server 块直接写 gzip_static on，应限定在静态资源 location 中
• 推荐用正则匹配后缀：location ~* \.(js|css|json|svg|woff2?|ttf|eot)$
• 该 location 内必须包含 root 或 alias，确保 Nginx 能按路径定位到磁盘上的 .gz 文件
• 避免与 try_files 冲突：gzip_static 在 try_files 执行前触发，若 try_files $uri 指向的是无 .gz 的路径，会跳过

验证是否真正起效，不能只看响应头

仅凭 Content-Encoding: gzip 无法区分是预压缩还是动态压缩的结果：

• 检查响应的 Content-Length 是否等于本地 .gz 文件大小（用 ls -l xxx.js.gz 对比）
• 查看响应头中 ETag 值是否由 .gz 文件的 inode + mtime 组成（而非原始文件）
• 用 curl -I -H "Accept-Encoding: gzip" https://yoursite.com/static/app.js，再对比原始文件和 .gz 文件的修改时间是否一致
• 若发现变慢，大概率是 .gz 缺失或 mtime 不同步，Nginx 会多一次 stat 系统调用回退到动态压缩

与其他压缩配置协同工作

gzip_static 和 gzip 可共存，但需明确分工：

• 保持 gzip on 全局开启，作为兜底：处理漏掉的静态文件或动态接口响应
• gzip_static on 专用于已预压缩的静态资源，优先级更高
• 关闭 gzip_vary off（即设为 gzip_vary on），否则 CDN 可能缓存错误版本
• 静态资源 location 中无需重复写 gzip 相关指令，避免覆盖或冗余