基岩版附加包就是一个 zip，而清单文件正是它加载失败的原因
大多数被拒绝导入的 .mcaddon 其实是一个有效的 zip，只是有一行头部信息写错了，而错误提示从来不会指出到底是哪个字段出了问题，常见原因还包括头部与模块 UUID 重复，以及压缩包里多套了一层文件夹。
.mcaddon 本质上是一个改了扩展名的 zip 压缩包，而游戏拒绝它的原因跟 zip 本身毫无关系。最常见的罪魁祸首是 manifest.json——这个小小的文件里有一个头部 UUID 和一个模块 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.mcmeta，用来声明它支持的格式（当前版本上是 min_format 和 max_format）。基岩版附带的则是 manifest.json，里面是 UUID 和模块列表。这两个文件互不被对方版本读取，也不能靠给压缩包改个名字就把资源包移植过去。
导入之前先检查
解压压缩包，看看最顶层。如果资源包多套了一层文件夹——是 MyPack/manifest.json 而不是 manifest.json——导入后会什么都没有，而且不报任何错误。清单文件必须位于每个资源包的根目录，和它所描述的各个文件夹并列。
方块模型是另一套格式
Java 版的方块模型 JSON 不是基岩版的几何文件，两者不能互换。Java 版模型通常只是一个 parent 加上一张 textures 映射——只有需要自定义形状时才要用 elements 列出长方体——而基岩版用自己的 minecraft:geometry 格式来描述形状。两者的度量都是 16 单位等于一个方块，这就是为什么同一个模型可能在一个版本里看起来没问题，在另一个版本里导入后却什么都没有。
注册名不能互换
基岩版和 Java 版对同样的内容使用不同的标识符。如果资源包引用了 Java 版的附魔、状态效果或生物群系名称，它会正常加载，然后悄无声息地什么都不做，因为这个名称解析不到任何条目。两个版本的注册表本身在规模上就有差异，所以针对某一个版本的列表编写的资源包，不能想当然地认为在另一个版本里也是完整的。
验证清单文件、检查压缩包结构，并在 Bedrock & Pack Tools 中生成方块模型。