简介这份资源是《我的世界》1.7.10免费版的项目源码包面向希望研究游戏底层实现、尝试二次开发或制作插件模组的开发者与进阶玩家。压缩包仅5KB共3个文件以html页面、inscode配置和gitignore忽略规则为主体量轻巧便于快速浏览与版本管理。该版本在玩法上加入了地图上传工具、Realms领域托管、玩家活动监视器与命令方块支持并修复了若干影响体验的BUG运行需JAVA环境及.NET Framework 2.0以上。源码的开放让开发者能深入探索游戏机制在此基础上开发修改版本或插件也为社区交流与创新提供技术基础。目前已有133人学习关注适合想从代码层面理解Minecraft实现原理、积累项目结构经验的读者参考。1. 一个十年前的方块世界为什么还有人愿意翻出源码重编译「我的世界1.7.10免费版[项目源码]」这个标题放在今天看其实挺反直觉的。一个 2014 年前后的老版本官方启动器早就默认推荐新版可偏偏有一批人还在折腾 1.7.10甚至要拿到项目源码自己编译、自己改。原因不复杂1.7.10 是模组生态最繁荣的一个分水岭大量经典模组、整合包、服务端插件都停在这个版本上新版反而跑不起来。所以这里的「免费版」不是指盗版而是指用开源或可获取的源码自己构建一个能跑、能改、能长期维护的客户端或服务端。这篇文章面向三类人想复现老版本环境的服主、想读源码学游戏架构的开发者、以及想给 1.7.10 写模组但被构建环境卡住的新手。我会把「拿到源码之后怎么编译、怎么跑、参数怎么调、哪里最容易翻车」讲清楚不涉及任何分发渠道只讲技术路径。2. 先搞清楚 1.7.10 源码到底包含什么客户端、服务端与映射表2.1 三份代码的关系别一上来就全量编译很多人拿到一个 1.7.10 的源码包第一反应是直接跑构建命令结果卡在依赖下载或者反混淆阶段。常见做法是先分清三块内容客户端代码、服务端代码、以及混淆映射表。1.7.10 时代的官方代码是混淆过的类名像aab、bca这种真正能读的是经过映射mapping之后的版本。映射表决定了你看到的net.minecraft.world.World到底对应混淆名是什么。如果你只想要一个能跑的服务端其实不需要完整客户端资源服务端 jar 的构建路径更短。我一般会先看目录里有没有conf或mappings文件夹里面通常是joined.srg、client.srg、server.srg这类文件。有映射表说明这个源码包是给开发者读的没有那可能只是一个反编译产物读起来会很痛苦。另一个判断点是build.gradle里有没有forge或fml相关插件1.7.10 的模组开发几乎绕不开 Forge源码构建也通常挂在 ForgeGradle 上。2.2 用 Gradle 拉齐依赖并生成可读源码1.7.10 的构建环境对 JDK 版本很敏感这是第一个硬门槛。它需要 JDK 8JDK 11 以上会在字节码处理阶段直接报错。下面是一个最小化的构建命令序列假设你已经装好 JDK 8 并配置了JAVA_HOME。# 确认 JDK 版本必须是 1.8.x java -version # 进入源码根目录先看 Gradle Wrapper 版本 cat gradle/wrapper/gradle-wrapper.properties # 执行 ForgeGradle 的初始化任务生成反混淆后的源码 ./gradlew setupDecompWorkspace # 如果只需要服务端环境可以只跑服务端分支 ./gradlew setupDecompWorkspace --refresh-dependenciessetupDecompWorkspace这个任务做三件事下载 Minecraft 原版 jar、应用映射表做反混淆、把结果放进build/decomp目录。--refresh-dependencies用于强制刷新依赖当你换了网络环境或者本地缓存损坏时很有用。执行完之后build/decomp下的代码就是可读的 Java 源码类名和方法名都恢复成正常命名。参数上最常调的是 Gradle 的 JVM 内存。1.7.10 反混淆很吃内存默认 512M 经常 OOM。可以在gradle.properties里加org.gradle.jvmargs-Xmx3G -Xms1G org.gradle.daemontrue-Xmx3G是上限机器内存小于 8G 就调到 2G再小会频繁 GC。org.gradle.daemontrue让后续构建复用进程省掉重复启动开销。2.3 生成 IDE 工程并验证源码可读反混淆完成后下一步是生成 IDE 能识别的工程文件。Eclipse 和 IDEA 的命令不同# 生成 Eclipse 工程 ./gradlew eclipse # 生成 IDEA 工程 ./gradlew idea生成之后用 IDE 打开重点看两个地方一是net.minecraft包下的类能不能正常跳转二是World.java里的方法有没有参数名。如果方法参数显示成var1、var2说明映射表只做了类名映射没做参数映射这在 1.7.10 里很常见不影响编译但读代码会累一点。验证源码可读之后再跑一次./gradlew build能出 jar 就说明整条链路通了。3. 编译出可运行的服务端从 build.gradle 到启动脚本3.1 改 build.gradle 里的三个关键字段1.7.10 的build.gradle通常长这样重点是minecraft块里的版本号minecraft { version 1.7.10-10.13.4.1614-1.7.10 runDir run mappings stable_12 }version字段是 Forge 版本加 MC 版本10.13.4.1614是 Forge 构建号后面跟的1.7.10是 MC 版本。这个字段写错会直接导致依赖拉不到。runDir是运行目录客户端和服务端的存档、配置、日志都落在这里。mappings是映射表版本stable_12是 1.7.10 时代常用的稳定映射换成别的版本可能导致方法签名对不上。如果你只要服务端可以在build.gradle里把客户端相关任务排除减少构建时间。常见做法是只保留jar任务跳过sourceJar和javadoc。另外repositories块里如果引用了已经下线的仓库地址构建会卡在解析依赖这时候把失效仓库注释掉换成mavenCentral()加本地缓存。3.2 构建服务端 jar 并写启动脚本构建命令本身很简单# 清理旧产物后重新构建 ./gradlew clean build # 产物通常在 build/libs 下 ls -lh build/libs/产物一般有两个一个不带-sources的是可运行 jar一个带-sources的是源码 jar。服务端启动需要的是前者。启动脚本要显式指定内存和 jar 路径#!/bin/bash # start_server.sh java -Xmx4G -Xms2G \ -XX:UseG1GC \ -XX:MaxGCPauseMillis100 \ -jar build/libs/server-1.7.10.jar \ nogui-Xmx4G是最大堆1.7.10 服务端在 10 人以内 2G 够用装了大量模组就往上加。-XX:UseG1GC在 1.7.10 上不是默认的但实测比默认的 Parallel GC 停顿更短。nogui参数让服务端不弹图形窗口纯命令行运行适合放在后台。第一次启动会在run目录生成eula.txt需要手动改成eulatrue才能继续这是很多人第一次跑服务端时卡住的地方。3.3 验证服务端是否真的跑起来了启动后不要只看有没有报错要看三个信号控制台出现Done字样、run/logs/latest.log里没有FATAL、以及用客户端能连上本地端口。如果卡在Preparing start region很久通常是世界生成在跑属于正常现象但超过五分钟就要看是不是模组冲突。验证连通性可以用一个简单的 TCP 检查# 检查 25565 端口是否在监听 ss -tlnp | grep 25565 # 看最近日志里有没有异常堆栈 grep -i exception\|error run/logs/latest.log | tail -20端口在监听、日志无异常、客户端能进这三条都满足才算真正跑通。只满足前两条但客户端连不上多半是server.properties里的online-mode或者server-ip配置问题。4. 避坑1.7.10 源码构建里最容易翻车的五件事4.1 现象构建卡在Downloading Minecraft不动原因1.7.10 的依赖下载地址是十年前的很多已经失效或者限速Gradle 默认超时时间又短。解决在gradle.properties里加大超时并配置本地缓存优先。可以加systemProp.org.gradle.internal.http.connectionTimeout120000和systemProp.org.gradle.internal.http.socketTimeout120000。如果还是不行手动把原版 jar 放进 Gradle 缓存目录让构建跳过下载。4.2 现象反混淆阶段报OutOfMemoryError: Java heap space原因前面提过反混淆是内存大户默认堆太小。解决把org.gradle.jvmargs的-Xmx调到 3G 以上同时关掉其他占内存的进程。如果机器只有 8G 内存把 IDE 关掉再跑构建构建完再开 IDE。4.3 现象编译通过但启动时报NoSuchMethodError原因映射表版本和 Forge 版本不匹配编译时用的方法签名和运行时 jar 里的对不上。解决确认build.gradle里mappings和version是配套的1.7.10 常用组合是stable_12配10.13.4.1614。换映射表之后必须重新跑setupDecompWorkspace不能只重新build。4.4 现象服务端启动后玩家一进就崩日志指向某个模组原因1.7.10 模组之间的 ASM 字节码注入冲突很常见尤其是两个模组都改了同一个类。解决二分法排查先只留核心模组启动确认能进再逐个加回。日志里看Caused by后面的类名定位是哪个模组注入的。临时规避可以在配置文件里关掉冲突模组的对应功能但根治要靠换模组版本或改加载顺序。4.5 现象改了源码重新构建但运行结果没变化原因Gradle 增量构建缓存没失效或者运行目录里用的是旧 jar。解决先./gradlew clean再build然后确认启动脚本指向的是build/libs下最新时间戳的 jar。另一个隐蔽原因是run目录里可能有旧的mods文件夹里面的旧模组覆盖了新构建的类清空run/mods再试。5. 进阶用源码做模组热调试和版本差异对比5.1 在 IDE 里直接跑客户端做热调试比起每次构建 jar 再启动更高效的方式是在 IDE 里直接跑runClient任务。ForgeGradle 会生成一个运行配置断点可以直接打在源码里。具体做法是在build.gradle里确认有runClient任务然后在 IDEA 的 Gradle 面板里双击执行。第一次跑会生成run目录之后改代码只要重新跑这个任务不用重新构建 jar。热调试的价值在于你能看到模组加载的完整调用栈尤其是FMLPreInitializationEvent阶段的注册顺序这对排查模组冲突非常有用。5.2 用源码对比 1.7.10 和后续版本的 API 差异如果你在把老模组往新版本迁移源码是最好的参照物。把 1.7.10 的反混淆源码和后续版本的反混淆源码并排打开重点看三个类Block、Item、World。1.7.10 里Block的注册还是用GameRegistry.registerBlock后续版本改成了注册表事件。方法签名上1.7.10 的getBlockMetadata在后续版本被拆成了getMetaFromState和getStateFromMeta。这些差异在源码里看一遍比读迁移文档记得牢。5.3 一个具体技巧用映射表反查混淆名有时候你拿到一个报错堆栈里面是混淆名比如aab.a(World.java:123)想定位到源码里的哪一行。做法是打开conf目录下的.srg文件搜索混淆名找到对应的可读名再在反混淆源码里搜可读名。这个过程手动做很慢可以写个小脚本# map_lookup.py # 在 srg 文件里反查混淆名对应的可读名 import sys def lookup(srg_path, obf_name): with open(srg_path, r, encodingutf-8) as f: for line in f: parts line.strip().split() # srg 格式通常是 PK: 可读名 混淆名 if len(parts) 3 and parts[2] obf_name: return parts[1] return None if __name__ __main__: result lookup(conf/joined.srg, sys.argv[1]) print(result if result else not found)这个脚本读joined.srg按行拆分后比对第三列。PK:开头的行是包名映射CL:是类映射FD:是字段映射MD:是方法映射。实际用的时候把报错里的混淆名传进去就能拿到可读名。注意 srg 文件很大逐行读没问题但别一次性全加载进内存。5.4 我踩过的一个坑别在源码里直接改原版类刚开始读源码的时候我图省事直接在net.minecraft包下的类里加日志结果构建出来的 jar 在别的机器上跑就崩。原因是原版类被 Forge 的字节码补丁依赖你改了源码补丁的偏移量就对不上了。正确做法是写一个独立的模组类用事件监听的方式注入逻辑而不是改原版源码。这个习惯我保持到现在源码只读不改要改就通过 Forge 的事件总线或者 ASM 在加载阶段注入。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/20 9:57:05 · 阅读 1.2k 我的世界1.7.10源码编译指南：从环境搭建到服务端运行
简介这份资源是《我的世界》1.7.10免费版的项目源码包面向希望研究游戏底层实现、尝试二次开发或制作插件模组的开发者与进阶玩家。压缩包仅5KB共3个文件以html页面、inscode配置和gitignore忽略规则为主体量轻巧便于快速浏览与版本管理。该版本在玩法上加入了地图上传工具、Realms领域托管、玩家活动监视器与命令方块支持并修复了若干影响体验的BUG运行需JAVA环境及.NET Framework 2.0以上。源码的开放让开发者能深入探索游戏机制在此基础上开发修改版本或插件也为社区交流与创新提供技术基础。目前已有133人学习关注适合想从代码层面理解Minecraft实现原理、积累项目结构经验的读者参考。1. 一个十年前的方块世界为什么还有人愿意翻出源码重编译「我的世界1.7.10免费版[项目源码]」这个标题放在今天看其实挺反直觉的。一个 2014 年前后的老版本官方启动器早就默认推荐新版可偏偏有一批人还在折腾 1.7.10甚至要拿到项目源码自己编译、自己改。原因不复杂1.7.10 是模组生态最繁荣的一个分水岭大量经典模组、整合包、服务端插件都停在这个版本上新版反而跑不起来。所以这里的「免费版」不是指盗版而是指用开源或可获取的源码自己构建一个能跑、能改、能长期维护的客户端或服务端。这篇文章面向三类人想复现老版本环境的服主、想读源码学游戏架构的开发者、以及想给 1.7.10 写模组但被构建环境卡住的新手。我会把「拿到源码之后怎么编译、怎么跑、参数怎么调、哪里最容易翻车」讲清楚不涉及任何分发渠道只讲技术路径。2. 先搞清楚 1.7.10 源码到底包含什么客户端、服务端与映射表2.1 三份代码的关系别一上来就全量编译很多人拿到一个 1.7.10 的源码包第一反应是直接跑构建命令结果卡在依赖下载或者反混淆阶段。常见做法是先分清三块内容客户端代码、服务端代码、以及混淆映射表。1.7.10 时代的官方代码是混淆过的类名像aab、bca这种真正能读的是经过映射mapping之后的版本。映射表决定了你看到的net.minecraft.world.World到底对应混淆名是什么。如果你只想要一个能跑的服务端其实不需要完整客户端资源服务端 jar 的构建路径更短。我一般会先看目录里有没有conf或mappings文件夹里面通常是joined.srg、client.srg、server.srg这类文件。有映射表说明这个源码包是给开发者读的没有那可能只是一个反编译产物读起来会很痛苦。另一个判断点是build.gradle里有没有forge或fml相关插件1.7.10 的模组开发几乎绕不开 Forge源码构建也通常挂在 ForgeGradle 上。2.2 用 Gradle 拉齐依赖并生成可读源码1.7.10 的构建环境对 JDK 版本很敏感这是第一个硬门槛。它需要 JDK 8JDK 11 以上会在字节码处理阶段直接报错。下面是一个最小化的构建命令序列假设你已经装好 JDK 8 并配置了JAVA_HOME。# 确认 JDK 版本必须是 1.8.x java -version # 进入源码根目录先看 Gradle Wrapper 版本 cat gradle/wrapper/gradle-wrapper.properties # 执行 ForgeGradle 的初始化任务生成反混淆后的源码 ./gradlew setupDecompWorkspace # 如果只需要服务端环境可以只跑服务端分支 ./gradlew setupDecompWorkspace --refresh-dependenciessetupDecompWorkspace这个任务做三件事下载 Minecraft 原版 jar、应用映射表做反混淆、把结果放进build/decomp目录。--refresh-dependencies用于强制刷新依赖当你换了网络环境或者本地缓存损坏时很有用。执行完之后build/decomp下的代码就是可读的 Java 源码类名和方法名都恢复成正常命名。参数上最常调的是 Gradle 的 JVM 内存。1.7.10 反混淆很吃内存默认 512M 经常 OOM。可以在gradle.properties里加org.gradle.jvmargs-Xmx3G -Xms1G org.gradle.daemontrue-Xmx3G是上限机器内存小于 8G 就调到 2G再小会频繁 GC。org.gradle.daemontrue让后续构建复用进程省掉重复启动开销。2.3 生成 IDE 工程并验证源码可读反混淆完成后下一步是生成 IDE 能识别的工程文件。Eclipse 和 IDEA 的命令不同# 生成 Eclipse 工程 ./gradlew eclipse # 生成 IDEA 工程 ./gradlew idea生成之后用 IDE 打开重点看两个地方一是net.minecraft包下的类能不能正常跳转二是World.java里的方法有没有参数名。如果方法参数显示成var1、var2说明映射表只做了类名映射没做参数映射这在 1.7.10 里很常见不影响编译但读代码会累一点。验证源码可读之后再跑一次./gradlew build能出 jar 就说明整条链路通了。3. 编译出可运行的服务端从 build.gradle 到启动脚本3.1 改 build.gradle 里的三个关键字段1.7.10 的build.gradle通常长这样重点是minecraft块里的版本号minecraft { version 1.7.10-10.13.4.1614-1.7.10 runDir run mappings stable_12 }version字段是 Forge 版本加 MC 版本10.13.4.1614是 Forge 构建号后面跟的1.7.10是 MC 版本。这个字段写错会直接导致依赖拉不到。runDir是运行目录客户端和服务端的存档、配置、日志都落在这里。mappings是映射表版本stable_12是 1.7.10 时代常用的稳定映射换成别的版本可能导致方法签名对不上。如果你只要服务端可以在build.gradle里把客户端相关任务排除减少构建时间。常见做法是只保留jar任务跳过sourceJar和javadoc。另外repositories块里如果引用了已经下线的仓库地址构建会卡在解析依赖这时候把失效仓库注释掉换成mavenCentral()加本地缓存。3.2 构建服务端 jar 并写启动脚本构建命令本身很简单# 清理旧产物后重新构建 ./gradlew clean build # 产物通常在 build/libs 下 ls -lh build/libs/产物一般有两个一个不带-sources的是可运行 jar一个带-sources的是源码 jar。服务端启动需要的是前者。启动脚本要显式指定内存和 jar 路径#!/bin/bash # start_server.sh java -Xmx4G -Xms2G \ -XX:UseG1GC \ -XX:MaxGCPauseMillis100 \ -jar build/libs/server-1.7.10.jar \ nogui-Xmx4G是最大堆1.7.10 服务端在 10 人以内 2G 够用装了大量模组就往上加。-XX:UseG1GC在 1.7.10 上不是默认的但实测比默认的 Parallel GC 停顿更短。nogui参数让服务端不弹图形窗口纯命令行运行适合放在后台。第一次启动会在run目录生成eula.txt需要手动改成eulatrue才能继续这是很多人第一次跑服务端时卡住的地方。3.3 验证服务端是否真的跑起来了启动后不要只看有没有报错要看三个信号控制台出现Done字样、run/logs/latest.log里没有FATAL、以及用客户端能连上本地端口。如果卡在Preparing start region很久通常是世界生成在跑属于正常现象但超过五分钟就要看是不是模组冲突。验证连通性可以用一个简单的 TCP 检查# 检查 25565 端口是否在监听 ss -tlnp | grep 25565 # 看最近日志里有没有异常堆栈 grep -i exception\|error run/logs/latest.log | tail -20端口在监听、日志无异常、客户端能进这三条都满足才算真正跑通。只满足前两条但客户端连不上多半是server.properties里的online-mode或者server-ip配置问题。4. 避坑1.7.10 源码构建里最容易翻车的五件事4.1 现象构建卡在Downloading Minecraft不动原因1.7.10 的依赖下载地址是十年前的很多已经失效或者限速Gradle 默认超时时间又短。解决在gradle.properties里加大超时并配置本地缓存优先。可以加systemProp.org.gradle.internal.http.connectionTimeout120000和systemProp.org.gradle.internal.http.socketTimeout120000。如果还是不行手动把原版 jar 放进 Gradle 缓存目录让构建跳过下载。4.2 现象反混淆阶段报OutOfMemoryError: Java heap space原因前面提过反混淆是内存大户默认堆太小。解决把org.gradle.jvmargs的-Xmx调到 3G 以上同时关掉其他占内存的进程。如果机器只有 8G 内存把 IDE 关掉再跑构建构建完再开 IDE。4.3 现象编译通过但启动时报NoSuchMethodError原因映射表版本和 Forge 版本不匹配编译时用的方法签名和运行时 jar 里的对不上。解决确认build.gradle里mappings和version是配套的1.7.10 常用组合是stable_12配10.13.4.1614。换映射表之后必须重新跑setupDecompWorkspace不能只重新build。4.4 现象服务端启动后玩家一进就崩日志指向某个模组原因1.7.10 模组之间的 ASM 字节码注入冲突很常见尤其是两个模组都改了同一个类。解决二分法排查先只留核心模组启动确认能进再逐个加回。日志里看Caused by后面的类名定位是哪个模组注入的。临时规避可以在配置文件里关掉冲突模组的对应功能但根治要靠换模组版本或改加载顺序。4.5 现象改了源码重新构建但运行结果没变化原因Gradle 增量构建缓存没失效或者运行目录里用的是旧 jar。解决先./gradlew clean再build然后确认启动脚本指向的是build/libs下最新时间戳的 jar。另一个隐蔽原因是run目录里可能有旧的mods文件夹里面的旧模组覆盖了新构建的类清空run/mods再试。5. 进阶用源码做模组热调试和版本差异对比5.1 在 IDE 里直接跑客户端做热调试比起每次构建 jar 再启动更高效的方式是在 IDE 里直接跑runClient任务。ForgeGradle 会生成一个运行配置断点可以直接打在源码里。具体做法是在build.gradle里确认有runClient任务然后在 IDEA 的 Gradle 面板里双击执行。第一次跑会生成run目录之后改代码只要重新跑这个任务不用重新构建 jar。热调试的价值在于你能看到模组加载的完整调用栈尤其是FMLPreInitializationEvent阶段的注册顺序这对排查模组冲突非常有用。5.2 用源码对比 1.7.10 和后续版本的 API 差异如果你在把老模组往新版本迁移源码是最好的参照物。把 1.7.10 的反混淆源码和后续版本的反混淆源码并排打开重点看三个类Block、Item、World。1.7.10 里Block的注册还是用GameRegistry.registerBlock后续版本改成了注册表事件。方法签名上1.7.10 的getBlockMetadata在后续版本被拆成了getMetaFromState和getStateFromMeta。这些差异在源码里看一遍比读迁移文档记得牢。5.3 一个具体技巧用映射表反查混淆名有时候你拿到一个报错堆栈里面是混淆名比如aab.a(World.java:123)想定位到源码里的哪一行。做法是打开conf目录下的.srg文件搜索混淆名找到对应的可读名再在反混淆源码里搜可读名。这个过程手动做很慢可以写个小脚本# map_lookup.py # 在 srg 文件里反查混淆名对应的可读名 import sys def lookup(srg_path, obf_name): with open(srg_path, r, encodingutf-8) as f: for line in f: parts line.strip().split() # srg 格式通常是 PK: 可读名 混淆名 if len(parts) 3 and parts[2] obf_name: return parts[1] return None if __name__ __main__: result lookup(conf/joined.srg, sys.argv[1]) print(result if result else not found)这个脚本读joined.srg按行拆分后比对第三列。PK:开头的行是包名映射CL:是类映射FD:是字段映射MD:是方法映射。实际用的时候把报错里的混淆名传进去就能拿到可读名。注意 srg 文件很大逐行读没问题但别一次性全加载进内存。5.4 我踩过的一个坑别在源码里直接改原版类刚开始读源码的时候我图省事直接在net.minecraft包下的类里加日志结果构建出来的 jar 在别的机器上跑就崩。原因是原版类被 Forge 的字节码补丁依赖你改了源码补丁的偏移量就对不上了。正确做法是写一个独立的模组类用事件监听的方式注入逻辑而不是改原版源码。这个习惯我保持到现在源码只读不改要改就通过 Forge 的事件总线或者 ASM 在加载阶段注入。希望帮到你。本文还有配套的精品资源点击获取