iNeedZIP、gzip 与 Brotli
外层 ZIP
使用标准 ZIP 的 Store（方法 0）或 Deflate（方法 8）。不使用加密 ZIP、分卷或自解压包；不要交付 RAR / 7z / tar.gz 作为上传包。不依赖 ZIP64、LZMA 或 Zstandard 等未验证的归档变体。
推荐普通 Deflate；“压缩级别越高”不等于浏览器加载越快，因为浏览器访问的是解开 ZIP 后的资源。对已有压缩资源使用 Store 也可以；最终必须以平台验证结果为准。
Godot 预压缩
平台接收的组合见文件类型。压缩不是必选项，未压缩的有效 WASM/PCK/JS 也可托管；包体接近限额时，可离线生成 gzip 或 Brotli 版本，并同步更新加载器请求路径。
- gzip 文件必须真正是 gzip 数据；Brotli 文件必须可被 Brotli 解码。
- 响应
Content-Encoding必须分别为gzip或br；Content-Type按去掉压缩后缀的逻辑资源确定。 - 平台在上传、存储、复制、网关和分发时保留编码元数据；WASM 解码后检查 v1 文件头，PCK 检查 GDPC 文件头。
- 不把 gzip/br 再解码后仍设置编码头，不对同一响应重复编码。
- 浏览器已经按响应头解码时，不再在游戏里手动解压一次。
保持资源一致
不要只压缩资源却不改加载器引用，也不要改引用后漏上传资源。若 loader 记录大小，须遵循该版本 loader 对大小的定义，实际启动测试不能省略。JS、WASM、PCK 和 worklet 来自同一导出批次，不混用不同 Godot 模板。
仅提供包内 _headers 或 .htaccess 不会改变平台响应头；它们不是用户可控制的服务器配置。若请求返回 MIME/编码错误，提交请求 URL、响应头、资源哈希与报错定位，不要求关闭隔离或开放任意响应头。
验证清单
- 记录每个资源的存储大小及解码大小，满足两套容量限制。
- 检查 HTML/loader 引用的 URL 与 ZIP 路径一致，无原件和压缩件的无意重复下载。
- 在真实 HTTP 环境启动；
file://打开成功不能作为托管验收。 - 检查状态码、Content-Type、Content-Encoding、错误控制台和完整玩法启动。
- 分别测试冷缓存、返回、重新开局与刷新，区分请求数和实际传输量。