基岩版附加包就是一个 zip，而清单文件正是它失败的原因
大多数被拒绝的 .mcaddon 导入其实都是有效的 zip，只是有一行标头写错了，而错误信息从不会指出是哪个字段出了问题。
一个 .mcaddon 就是一个改了扩展名的 zip 压缩包，而游戏拒绝它的原因往往跟 zip 本身毫无关系。最常见的元凶是 manifest.json——这个小小的文件带有一个标头，其中两个 UUID 必须互不相同，而且它的 format_version 必须是你所针对的游戏版本。
两个 UUID，绝不能相同
清单文件包含一个 header 和一个 modules 数组。两者各自需要自己的 uuid，而在两者之间复用同一个 UUID 是最常见的被拒原因：
{
"format_version": 2,
"header": {
"name": "My Pack",
"description": "Example",
"uuid": "aaaaaaaa-0000-0000-0000-000000000000",
"version": [1, 0, 0],
"min_engine_version": [1, 21, 0]
},
"modules": [
{
"type": "data",
"uuid": "bbbbbbbb-0000-0000-0000-000000000001",
"version": [1, 0, 0]
}
]
}UUID 是 128 位的值，写作 32 个十六进制数字，分成五组、以连字符分隔。用什么生成器都行，重复就不行。version 和 min_engine_version 是三整数数组，不是字符串——"1.0.0" 在某些版本上会静默失败。
Java 根本没有清单文件
正是这个差异让在版本之间来回切换的人栽跟头。Java 资源包附带的是一个含有 pack_format 整数的 pack.mcmeta。基岩版附带的则是带有 UUID 和模块列表的 manifest.json。两个版本都不会读取对方的文件，也不能靠重命名压缩包来移植资源包。
导入之前先检查
解压压缩包，看看顶层。如果资源包多套了一层文件夹——是 MyPack/manifest.json 而不是 manifest.json——导入后会什么都没有，而且不报任何错误。清单文件必须与它所描述的 textures/ 或 behavior_packs/ 内容放在同一层。
方块模型是另一种格式
Java 的方块模型 JSON 不是基岩版的几何文件，两者不能互换：
| Java 方块模型 | 基岩版几何 | |
|---|---|---|
| 根键 | elements | minecraft:geometry |
| 坐标 | 每方块 0–16 | 每方块 0–16 |
| 纹理 | textures 映射 | materials 映射 |
两者都表示每方块 16 个单位的立方体网格，这就是为什么生成的模型在其中一个里看起来正常，导入到另一个里却变成一个空形状。
注册名不能互换
基岩版和 Java 对同样的内容使用不同的标识符。如果资源包引用了 Java 的附魔、效果或生物群系名称，它会正常加载，然后悄无声息地什么都不做，因为该名称解析不到任何条目。两个版本的注册表本身大小也不同，所以针对某一版本的列表编写的资源包，不能想当然地认为在另一版本里也是完整的。
验证清单文件、检查压缩包结构，并在 Bedrock & Pack Tools 中生成方块模型。