我开发附加包时遇到的离奇漏洞

Cat_A***

探索附加包开发中遇到的神秘漏洞，看如何巧妙化解。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

开发了三年附加包，我遇到过很多漏洞。有些只是简单的拼写错误，有些是功能的误用，有些则是至今解释不清的离奇漏洞，我挑选了五个最离奇的漏洞写成了这篇文章。

注：迷惑程度指这个漏洞花了我多久去解决它，迷惑程度越大，解决这个漏洞的耗时就越长。

神秘程度指这个漏洞的性质未解明的程度，神秘程度越大，这个漏洞的运作原理就越不清晰。

1. 忽略 use_modifiers 漏洞

名称	值
迷惑程度	★★★☆☆
神秘程度	★★☆☆☆

现象

在一次游戏版本更新后，我的附加包报错：“带有食物组件的物品需要定义它的使用时长”，而且那些食用后会清除状态效果的食物都不能完成食用了。

解决过程

由于我只是更新了一下游戏版本就出现了漏洞，我怀疑是他们更改了某些格式而没有写在更新日志里。

于是我决定使用二分法去寻找那个导致内容日志的物品文档，因为内容日志没有指出到底是哪个物品没有定义使用时长。

经过一番寻找，我发现了一个物品，运行这个物品时会报错，但不运行这个物品，运行其他一小部分物品不会报错。

我打开了这个物品文档，发现没什么特殊之处，只是用 remove_mob_effect 事件方法移除了食用者的状态效果而已。这让我百思不得其解，因为附加包中还有很多这样的物品，为什么它会导致报错，其他的物品不会？

进一步测试，我移除了物品定义中的食物组件等部分，将所有物品文档归位，让它们全部加载。但这次还是报错，我当时怀疑可能是什么随机性漏洞，它不会每次都出现，仅仅在特定情况下出现。或者涉及到了除物品定义以外的其他复杂变量，和我无法精确控制的变量。

于是这个漏洞存在了几周都没有被修复。直到那天，我才看出了端倪——为了使用物品事件，我把物品的格式版本设为 1.21.20，但我定义物品使用时长的方式是使用一个 1.21.50 才加入的组件——minecraft:use_modifiers。

将这个组件拆分为 minecraft:use_duration 和 minecraft:chargeable 后，内容日志不再出现，这个漏洞被修复了。

关键点

注意格式版本和物品组件的适用性。

2. menu_category 定义冲突崩溃漏洞

名称	值
迷惑程度	★★☆☆☆
神秘程度	★☆☆☆☆

现象

为了升级方块和物品的格式版本，我进行了一次大规模的方块和物品定义的修改。之后，我进入游戏测试，但游戏在“加载资源包”时毫无征兆地崩溃了。

解决过程

由于刚才大规模的定义修改，直接找出漏洞变得异常困难。这时候没什么好办法，只能通过二分法查找有问题的文件。

由于我的附加包新增了成百上千个方块和物品，我花了数小时才找到问题所在，还是一个看起来平平无奇的物品定义文件。检查之后，我发现我忘了删除 minecraft:creative_category 组件，结果这个组件和 menu_category 字段一起出现了。

我把旧写法删除掉，结果就正常了，漏洞解决了。这个漏洞其实相当简单，就是两个写法不能同时出现。但它离奇就离奇在，没有任何内容日志或者提示，而且在刚开始加载存档时（也就是提示“加载资源包”时）就崩溃了。

关键点

分次进行大规模的修改。

3. contents.json 漏洞

名称	值
迷惑程度	★★★★☆
神秘程度	★★☆☆☆

现象

我向附加包内加入了一些内容，比如新物品，但游戏没有加载这些物品。

解决过程

这个漏洞也相当离奇，就仅仅是加入物品都会出问题？实际上确实出了问题，而且当时我还不知道到底是哪里出了问题。

面对这样一个漏洞，当时我束手无策。我尝试加入新的方块，但方块仍然没有注册到游戏中。我认为是方块或物品的写法出了问题，导致游戏没法识别这些内容。

于是我参考了已经被我加入游戏的那些方块的定义文件，原封不动地加入了一个新方块，但方块仍然没有出现。可是原来的那个方块用的定义文件和我想要加入的新方块的定义文件在内容上都一样，再怎么说也不可能不行。

而且从可以加入新物品到不能加入新物品，我没有对附加包做任何更改，就连游戏版本也是几天之前更新的，而这几天我调整了不少方块的数值，也能正常生效。

此时，我只能做进一步的测试。我修改了原来加入的方块的 ID，游戏中的 ID 也变了，说明只是不能加入内容了，这就很奇怪。也许只是不能加入方块和物品，还能加入其他的？我加入了一个测试实体，也不行。一个粒子，还是不行，运行 particle 命令后没有显示那个粒子。

到了第二天，我发现实际上不是不能加入新内容，而是不能加入新文件。所有添加的文件都没有生效，而删除文件又不会导致内容日志方面的异常。

这说明可能是某个文件的问题，它存储了附加包中所有文件的列表。想到这里，答案已经很明显了——contents.json。

这个文件的作用是帮助游戏更快地判断附加包中有什么文件，加速附加包的加载。我是在好久之前加入的这个文件，也许有一次更新改变了这个文件的运行方式，导致游戏只会从这个文件中读取文件列表，而不检测没有在这里列出的文件。

这就好像一本书的目录，它写着有五章，但我们稍微翻翻就能发现它其实有十章。一开始游戏也是这么做的，但一次更新之后，它突然决定按照目录读，忽略实际上存在的后五章，只看完目录指向的前五章就断定读完了这本书。

于是我删除了这个文件，重新加载，漏洞就解决了。

关键点

不适用。

4. 子包崩溃漏洞

名称	值
迷惑程度	★★★★★
神秘程度	★★★☆☆

现象

在开发无框玻璃板时，为了优化性能，我制作了无框玻璃板的简化版本，是一些方块定义文件。为了在简化版本和完整版本之间选择，我加入了子包。所有简化版的文件放在根目录，完整版的放在子包，根据内存情况决定可以启用哪个子包。但选中任意的子包后，加载存档时会崩溃。

解决过程

难道子包不能用了吗？最近子包似乎确实有点问题，但还不至于让游戏崩溃。但这次不一样，不知道为什么，游戏直接崩溃了，没有任何内容日志。

于是我首先检查子包的写法是否正确，经过数次测试，我确定了子包的定义是正确的。当时有个问题，就是如果我们在一个方块上定义很多方块状态，游戏就会占用好几 GiB 内存。于是我认为是我加载了过多的方块定义文件，导致了崩溃。

所以我把子包里的完整版方块定义文件删除掉，这次果然不崩溃了。

漏洞就这么轻松地解决了吗？答案是，没有。因为即使是选择只加载一个完整版的文件，游戏依然会崩溃。但如果不用子包，而且把文件放在根目录去加载，游戏又不会崩溃了。

这说明，我的设备实际上可以加载出一个完整版文件，是子包让游戏崩溃了，而不是内存占用过多让游戏崩溃了。

这个问题困扰了我好几天。期间，我尝试了无数种办法，但就是没法搞明白子包到底如何让游戏崩溃。

但最后，我还是通过控制变量找到了答案，那就是子包只能有效地覆盖根目录没有的文件夹，如果根目录和子包有同样的文件夹，那么选中这个子包并加载就会让游戏崩溃。

于是，经过一些简单的处理，这个漏洞最后被我解决了。

关键点

不适用。

5. 拼图结构与计划刻崩溃漏洞

名称	值
迷惑程度	★★★★☆
神秘程度	★★★★☆

现象

最近我在开发下界工厂，一种在下界生成的拼图结构，原理就像猪灵堡垒一样。建造了几个结构模板后，我尝试生成这个拼图结构，但游戏崩溃了。

解决过程

拼图结构是个很新的东西，关于它的资料很少。比如，你大概率不知道拼图结构的模板池名称长度必须不超过 40 个字符（这应该是在 UI 层面做的限制），否则没法输入到拼图方块里。

出现这种情况，我只能慢慢加载所有的零部件，也就是那些结构模板，一个一个排查。我很快确定了，是“塔”结构出的问题。

也许是因为它用了太多拼图方块？为了让结构壮观一点，我给每个可能的方向都放了一个拼图方块。也许是因为它太大了？它的大小是 12 * 17 * 12，高度上正好超过了一个区块。

可能性有很多，我尝试了很久很久都没有找到结果，于是本来打算很快加入的下界工厂就拖到了现在。如果我们强行让它生成，那么在下界走上一段距离就会崩溃，就只是因为下界会生成这个拼图结构。

尝试了很久之后，今天（2025 年 2 月 3 日）我终于找到了解决办法。原来……是塔中间那些蒸汽喷推机出了问题！

不知道为什么，如果我们尝试放置一个包含带计划刻的方块的拼图结构，游戏就会崩溃。就是这个问题，困扰了我十几天。解决办法也很简单，我们先用其他方块代替蒸汽喷推机，到时候用处理器把方块替换回去就行了。于是，这个漏洞也被解决了。

关键点

不适用。