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