兄弟我之前在搞1.12.2 Forge模组的时候，也碰到过这种离谱到爆炸的问题！明明只有几十行的干净代码，构建的时候突然变成几千行的垃圾内容，还一堆莫名其妙的编译错误，简直头大到想砸键盘。给你说说最可能的几个原因和对应的解决办法：

最可能的原因及解决办法 #

1. Gradle构建缓存彻底抽风了 #

这是最常见的罪魁祸首，Gradle的缓存有时候会犯病，把之前构建残留的错误代码、半生成的无效代码缓存下来，每次构建就疯狂往目标文件里重复写入，直接把代码堆成几千行。

• 解决办法：在项目根目录直接运行 gradlew clean build，先彻底清理掉所有旧的构建文件和缓存数据，再重新执行构建。这个操作能解决至少80%的这种离谱构建问题。

2. 漏实现了Container的抽象方法 #

Forge 1.12.2的Container是抽象类，除了你已经实现的canInteractWith方法，还有一个必须实现的transferStackInSlot方法！虽然你的IDE可能没立刻报错，但Forge的构建插件可能会尝试自动补全这个方法的实现，结果补全逻辑出了bug，生成了几千行的垃圾代码。

• 解决办法：给ContainerATM类补上这个方法的实现，哪怕先写个空实现也行，比如：

@Override
protected void transferStackInSlot(EntityPlayer playerIn, int index) {
    // 后续你可以在这里实现背包与ATM槽位的物品转移逻辑，现阶段先留空即可
}

3. SourceSets配置搞出了循环引用 #

要是你手动修改过build.gradle里的sourceSets配置，不小心把构建输出目录（比如build/sources）也加到了源文件目录里，就会导致构建时循环读取、写入代码，越堆越多。

• 解决办法：打开build.gradle检查sourceSets部分的配置，确保只包含src/main/java这类真正的源文件目录，别把build/开头的输出目录加进去。

4. 字节码操作插件（ASM/Mixin）配置出错 #

如果你的项目里用了ASM或者Mixin来修改字节码，要是配置出了问题，可能会错误地把父类Container的所有字节码反编译成Java代码，强行插入到你的ContainerATM类里，直接导致代码膨胀。

• 解决办法：检查你的Mixin配置文件（比如mixins.xxx.json）和ASM相关的代码，确保没有错误地把ContainerATM作为目标进行过度的字节码注入操作。

你可以按这个顺序一个个试，先试gradlew clean build，再补全抽象方法，基本就能解决这个离谱的问题了。

内容来源于stack exchange