我的世界1.7.10源码编译与模组开发实战指南

简介：这份资源是《我的世界》1.7.10免费版的项目源码包，面向希望研究游戏底层实现、尝试二次开发或制作修改版本的开发者与进阶玩家。该版本新增地图上传工具与Realms领域功能，并加入玩家活动监视器、命令方块支持等特性，源码的开放让游戏机制更透明，便于在此基础上开发插件或定制版本。压缩包共3个文件，以html页面、inscode配置和gitignore忽略规则为主，整体仅约5KB，属于轻量级代码包，适合快速浏览项目结构与配置方式。目前已有133人学习下载，读者可从中了解该版本源码的组织形式与关键配置项，为后续深入阅读代码、理解启动与运行环境要求提供入口，也可作为个人研究或教学演示的参考素材。

1. 从一份 1.7.10 源码说起：为什么老版本 MC 至今还有人折腾

如果你在搜索引擎里敲下「我的世界1.7.10免费版 项目源码」，大概率不是想找一份能直接双击运行的整合包，而是想拿到一套能编译、能改、能塞进自己逻辑的 Java 工程。1.7.10 是 Minecraft 模组生态里一个绕不开的版本——Forge 的成熟度、映射表的稳定性、大量经典模组至今只停留在这个版本，让它成了很多人「第一次读源码」的起点。但现实是，网上流传的所谓源码包质量参差不齐，有的缺 Gradle 包装器，有的映射表对不上，有的干脆是反编译产物直接打包。这篇笔记就按一线折腾的顺序，把「拿到一份 1.7.10 源码后怎么让它跑起来、怎么改、坑在哪」讲清楚。适合有 Java 基础、想入门模组开发或做二次定制的从业者，新手能跟着命令走，熟手能直接跳到参数和排错部分。

2. 先分清三种「源码」：反编译、Forge MDK、完整工程

2.1 反编译产物和官方 MDK 的本质区别

很多人拿到手的「项目源码」其实是反编译 jar 包得到的.java文件堆。这类产物最大的问题是变量名全是var1、var2，控制流被混淆过，方法体里塞满了编译器生成的合成代码。它能读，但几乎不能改——你改完一个方法，重新编译时大概率因为泛型擦除或内部类引用对不上而失败。真正能用于二次开发的，是 Forge 官方提供的 MDK（Mod Development Kit），它包含build.gradle、gradle.properties、settings.gradle和一套标准的源码目录结构，配合 MCP 映射表把混淆名还原成可读名。判断标准很简单：打开根目录，有gradlew和build.gradle且src/main/java下包名是com.example之类的规范命名，才是能干活的东西。

2.2 1.7.10 版本的特殊性：为什么它和 1.12+ 的工程结构不一样

1.7.10 用的是 Forge 10.13.4.1614 这一支，构建系统还是 Gradle 2.x 时代的写法，没有official映射，依赖的是 MCP 的stable_12映射表。它的build.gradle里你会看到apply plugin: 'forge'而不是后来的net.minecraftforge.gradle独立插件写法。另一个关键差异是资源目录：1.7.10 的assets和mcmod.info直接放在src/main/resources下，不需要META-INF/mods.toml。如果你拿一份 1.12 的工程改版本号硬套，会在runClient阶段直接报NoClassDefFoundError，因为入口类注解@Mod的modid校验逻辑和FMLPreInitializationEvent的包路径都变了。

2.3 拿到源码包后的第一轮体检清单

在动手编译前，先花五分钟做这几项检查，能省掉后面几小时的报错排查：

提示：JDK 版本是 1.7.10 工程翻车率最高的点。用 JDK 17 跑gradlew setupDecompWorkspace会在 ForgeGradle 1.2 的字节码处理阶段直接抛Unsupported class file major version，别问我是怎么知道的。

3. 用 ForgeGradle 把 1.7.10 工程在本地跑起来

3.1 环境准备：JDK 8 与 Gradle 2.14 的固定搭配

1.7.10 的 ForgeGradle 插件版本是 1.2-SNAPSHOT，它依赖 Gradle 2.x 的 API。你系统里如果装了 Gradle 7 或 8，直接执行gradle命令会报Could not find method jcenter()。最稳的做法是：装一个 JDK 8（推荐 Temurin 8u392），然后不要用系统 Gradle，而是用工程自带的gradlew。如果工程里没有 wrapper，手动补一个gradle-wrapper.properties：

distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists distributionUrl=https\://services.gradle.org/distributions/gradle-2.14.1-bin.zip

这段配置指定了 Gradle 2.14.1 的下载地址，distributionUrl里的反斜杠是 properties 文件对冒号的转义，不能省。补完后在工程根目录执行./gradlew --version，看到Gradle 2.14.1才算环境对了。

3.2 首次构建：setupDecompWorkspace 到底在做什么

执行下面这条命令，这是 1.7.10 工程从源码到可运行的第一步：

./gradlew setupDecompWorkspace --refresh-dependencies

setupDecompWorkspace这个 task 做三件事：下载 Minecraft 客户端和服务端 jar、用 ForgeGradle 内置的 FernFlower 反编译器把混淆 jar 还原成带 MCP 映射的源码、生成 IDE 能识别的工程文件。--refresh-dependencies强制刷新依赖缓存，避免旧缓存里的映射表版本对不上。整个过程视网络情况要 5 到 20 分钟，卡在decompile阶段是正常的，别急着 Ctrl+C。如果卡在Downloading超过十分钟，检查build.gradle里的仓库地址是不是指向了已经关停的files.minecraftforge.net旧路径，换成https://maven.minecraftforge.net/即可。

3.3 生成 IDE 工程并跑起客户端

构建成功后，根据你用的 IDE 执行对应命令：

# 生成 Eclipse 工程 ./gradlew eclipse # 生成 IntelliJ IDEA 工程 ./gradlew genIntellijRuns

eclipsetask 会生成.classpath和.project文件，IDEA 用户则用genIntellijRuns生成运行配置。完成后在 IDE 里导入工程，找到runClient这个 Gradle task 或生成的 Application 配置，直接运行。第一次启动会看到 Minecraft 主界面，但标题栏会带Minecraft 1.7.10和 Forge 版本号。如果启动到一半闪退，看run/logs/latest.log，最常见的报错是java.lang.ClassNotFoundException: net.minecraft.launchwrapper.Launch，这说明setupDecompWorkspace没跑完就中断了，删掉build目录重跑一次。

3.4 验证源码可改：加一行日志看效果

在src/main/java下找到你的主类（带@Mod注解的那个），在preInit方法里加一行：

@Mod(modid = "examplemod", version = "1.0") public class ExampleMod { @Mod.EventHandler public void preInit(FMLPreInitializationEvent event) { // 输出到控制台，验证源码修改后能生效 System.out.println("[ExampleMod] preInit 已执行，源码可改"); } }

@Mod注解里的modid必须全小写且和mcmod.info里的modid一致，否则 Forge 在加载阶段会抛Invalid modid。preInit是 Forge 生命周期里最早的回调之一，在这里打日志能确认你的修改被编译进了最终产物。改完在 IDE 里重新运行runClient，控制台出现这行字，说明整条「改源码 → 编译 → 运行」的链路通了。

4. 改源码时最容易翻车的四个地方

4.1 现象：编译通过但游戏里方块贴图全紫黑

原因：1.7.10 的资源路径是硬编码在assets/<modid>/textures/blocks/下的，且setBlockTextureName里写的是modid:block_name格式。如果你从别的工程复制代码，modid没改，或者贴图文件名大小写和代码里不一致，就会走默认的紫黑缺失贴图。解决：检查src/main/resources/assets/<你的modid>/textures/blocks/下文件名是否全小写，代码里setBlockTextureName("yourmodid:your_block")的yourmodid必须和@Mod注解里的modid完全一致。

4.2 现象：runClient 启动时报 Duplicate modid

原因：build.gradle里的group和archivesBaseName如果和@Mod的modid撞了，或者你同时加载了两个modid相同的模组，Forge 的Loader会直接拒绝启动。解决：打开run/logs/latest.log搜索Duplicate mod，找到冲突的modid，改掉自己工程里的modid和mcmod.info中的对应字段。注意mcmod.info是 JSON 格式，少个逗号也会导致解析失败，但报错信息会伪装成modid重复。

4.3 现象：改了代码但游戏行为没变

原因：ForgeGradle 的增量编译在 1.7.10 上不太可靠，有时候build目录里的 class 文件没更新，IDE 又直接用了旧的。解决：执行./gradlew clean清掉build目录，再重新runClient。如果还不行，检查 IDE 的运行配置里Use classpath of module是不是指向了正确的模块，IDEA 有时候会默认选到_main而不是你的工程模块。

4.4 现象：setupDecompWorkspace 卡在 decompile 不动

原因：FernFlower 反编译整个 Minecraft jar 是 CPU 密集型任务，如果机器内存不足 4GB 或者 Gradle 的org.gradle.jvmargs设得太小，会卡死或 OOM。解决：在工程根目录建gradle.properties，加一行org.gradle.jvmargs=-Xmx4G，然后重新执行。如果网络下载 Minecraft jar 慢，可以手动把 jar 放到 Gradle 缓存目录，但路径因系统而异，不如挂个稳定的网络环境重试。

5. 从能跑到能发布：构建可分发 jar 与版本号管理

5.1 用 build 任务打出可用的模组 jar

源码跑通后，要给别人用就得打成 jar。执行：

./gradlew build

产物在build/libs/下，通常有两个文件：<archivesBaseName>-<version>.jar和-sources.jar。前者是发布用的，后者是源码包。archivesBaseName和version在build.gradle里定义，建议改成你的模组名-1.7.10-1.0.0这种格式，方便用户一眼看出适配版本。注意 1.7.10 的 jar 不需要签名，直接丢进.minecraft/mods就能加载，但前提是用户也装了对应版本的 Forge。

5.2 版本号与 mcmod.info 的联动

mcmod.info是 1.7.10 模组的元数据文件，放在src/main/resources/下。它的version字段和build.gradle里的version是两套东西：前者是游戏内显示的，后者是 jar 文件名用的。常见做法是用 Gradle 的processResources任务在构建时把build.gradle的版本号替换进mcmod.info，这样改一处就行。如果手动改，记得两个地方同步，否则用户看到的版本和文件名对不上，反馈问题时你根本分不清他用的哪一版。

5.3 发布前的最小验证清单

在把 jar 发出去之前，至少做这三步：把 jar 放进一个干净的、只装了 Forge 的 1.7.10 客户端里启动一次，确认没有Missing mods或崩溃；开一个新世界，放一个你的方块、合成一个你的物品，确认注册和贴图正常；看logs/latest.log里有没有WARNING级别的报错，尤其是Texture not found和Registry remapping相关的。这三步花不了十分钟，但能挡掉八成「下载后不能用」的差评。

6. 一个老版本工程的长期维护习惯

1.7.10 的工程最怕的就是「当时能跑，过半年换台机器就起不来」。我自己的习惯是：每拿到一份能跑的源码，先在根目录建一个ENV.md，记下 JDK 具体版本号（比如Temurin 8u392）、Gradle 版本、setupDecompWorkspace成功那次的完整命令和耗时、以及build.gradle里所有仓库地址的快照。这些东西看着琐碎，但当你半年后想加个新方块却发现环境全崩时，这份记录就是后悔药。另一个习惯是永远不用系统全局的 Gradle 和 JDK，全部走工程内 wrapper 和固定路径的 JDK，避免某次系统升级把 Java 升到 17 导致整个工程报废。老版本 MC 的折腾，本质上是在跟工具链的腐化赛跑，把环境钉死比什么都重要。希望帮到你。

本文还有配套的精品资源，点击获取