# ZIP、gzip 与 Brotli

## 外层 ZIP

使用标准 ZIP 的 Store（方法 0）或 Deflate（方法 8）。不使用加密 ZIP、分卷或自解压包；不要交付 RAR / 7z / tar.gz 作为上传包。不依赖 ZIP64、LZMA 或 Zstandard 等未验证的归档变体。

推荐普通 Deflate；“压缩级别越高”不等于浏览器加载越快，因为浏览器访问的是解开 ZIP 后的资源。对已有压缩资源使用 Store 也可以；最终必须以平台验证结果为准。

## Godot 预压缩

平台接收的组合见[文件类型](formats.md)。压缩不是必选项，未压缩的有效 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、响应头、资源哈希与报错定位，不要求关闭隔离或开放任意响应头。

## 验证清单

1. 记录每个资源的存储大小及解码大小，满足两套容量限制。
2. 检查 HTML/loader 引用的 URL 与 ZIP 路径一致，无原件和压缩件的无意重复下载。
3. 在真实 HTTP 环境启动；`file://` 打开成功不能作为托管验收。
4. 检查状态码、Content-Type、Content-Encoding、错误控制台和完整玩法启动。
5. 分别测试冷缓存、返回、重新开局与刷新，区分请求数和实际传输量。