mrpack 是一个谎称自己是 zip 的 zip
把 .mrpack 重命名为 .zip 后，你得到的只是一个 manifest 和一个 overrides 文件夹，而不是模组——jar 文件存放在 Modrinth 的 CDN 上，通过哈希值获取。
.mrpack 是一个 ZIP 压缩包，所以把它重命名为 .zip 再解压是可行的——但几乎得不到任何有用的东西。你会看到一个 modrinth.index.json、一个 overrides 文件夹，以及完全没有模组。jar 文件从来就不在里面。
为什么模组不见了
Modrinth 整合包存储的是清单（manifest），而不是实际内容。modrinth.index.json 中的每个条目列出了一个下载 URL，以及该 URL 应返回文件的 SHA-1 和 SHA-512 哈希值。启动器读取清单，获取每个文件，验证哈希值，然后才将其放入实例中。
这种设计让整合包保持小巧，并允许整合包在不重新上传每个 jar 的情况下更新。这也意味着，在有人解析过一次之前，整合包无法离线使用。
清单实际包含什么
| 字段 | 含义 |
|---|---|
formatVersion | 清单架构版本 |
game | 始终为 "minecraft"——版本信息位于 dependencies 中 |
files | 由 path、hashes、downloads、env 组成的数组 |
dependencies | 需要首先安装的加载器和 Minecraft 版本 |
每个文件上的 env 字段是人们容易忽略的那个。它分别针对 client 和 server 说明该文件是 required、optional 还是 unsupported——而没有 env 的文件在两者上都是必需的。标记为仅客户端的模组根本不应被复制到服务器的 mods 文件夹中——这样做是导致服务器拒绝启动的常见原因。
哈希校验不是可选项
如果下载文件的 SHA-1 与清单不匹配，那么该文件就是有问题的：下载被截断、CDN 错误页面被保存为 jar，或者镜像被篡改。跳过验证的转换器会心安理得地打包出一个损坏的实例。验证正是在本地进行此操作、而非信任随机重新打包的完整理由。
客户端与服务器输出
同一份清单会根据目标生成两种不同的压缩包：
- 客户端整合包——包含所有内容，外加在实例根目录合并的
overrides，可直接用于接受 ZIP 的启动器。 - 服务器整合包——跳过
env.server为unsupported的条目，保留其余部分，并将server-overrides/叠加到overrides/上，而不是client-overrides/。
仅限 Java 版。Bedrock 没有对应的格式；Bedrock 附加包是 .mcaddon/.mcpack 压缩包，其 manifest.json 结构完全不同，没有任何 Modrinth 整合包能解析为它们。
overrides 是覆盖，不是合并
overrides/ 下的文件会在模组放置完成后复制到实例上。overrides 中的配置文件会直接替换模组的默认配置。如果整合包在 overrides 中附带了一个配置文件，而你又在该实例中编辑了那个配置文件，那么在下一次解析时，overrides 中的副本会胜出。
转换清单，验证每一个哈希值，然后在 MRPACK 转 ZIP 转换器 中获取可直接用于启动器或服务器的 ZIP。