我的世界Overlay测试指南：拼好种与终末之诗通关验证

这次我们来看一个很具体的《我的世界》测试场景：在第 25 天的生存档里，用一个预先拼好的种子图（下称“拼好种”）启动了一轮 overlay 功能测试，最后在 14:14 这个时间点进入终末之诗，完成一次通关验证。如果把这句话拆开看，它的技术含量其实不低：overlay 并不是某一个单一模组，而是资源包覆盖层、区块/结构边框叠加、F3 调试信息、光影覆层、录制时相机信息叠加这一整套“绘制在游戏画面之上”的机制。测试的意义在于：通过一组可复现的种子和目录配置，验证 overlay 是否生效、配置是否正确、对性能有多大影响，以及能不能在测试过程中顺利跑完末地流程。

这篇文章会按本地部署和功能验证的思路整理一套完整流程：先解释 overlay 在《我的世界》中的几种常见形态，再给资源包 overlay 目录的配置模板、拼好种与存档准备方式、通关测试步骤、录制时 overlay 相机信息叠加方案，最后补充性能观察、常见问题和批量配置脚本。内容会尽量保持“先看能不能用，再讲怎么用”的节奏，命令和配置都能直接复制测试，但涉及版本号、显存占用、帧数这类与本机环境强相关的参数，我不会编造，只会给出观察方法和判断思路。

如果你属于下面三类读者，这篇文章可以直接收藏：

1. 正在做《我的世界》资源包或模组整合包的开发者，需要搞清楚 overlay 目录的正确写法。
2. 想通过可视化 overlay 辅助通关、定位要塞、分析地图结构的玩家。
3. 需要把《我的世界》测试流程工程化的内容创作者，包括录制“overlay 相机”视角、批量切换资源包、保存可复现存档等场景。

1. 核心能力速览

1.1 这次测试到底是什么

“学习玩我的世界第25天，用拼好种测试overlay 14:14进入终末之诗”这个标题本质上是一次“可复现的 Minecraft 测试用例”。它不像普通开荒视频那样随机生成地图，而是把种子、资源包、overlay 配置、通关路径这几个变量固定下来，让每一次测试都能落到同一张地图上。

从标题用词看，“拼好种”可以理解为一套经过预先拼接和挑选的种子/存档方案。它的作用是保证测试环境一致：地图结构相同、要塞位置相同、末地传送门生成规则相同，从而让 overlay 功能的验证结果具备可比性。如果没有这套方案，每次进游戏地形都不一样，看不清 overlay 是否真的生效。

“14:14 进入终末之诗”则是测试流程里的时间基准点。它可能是游戏内时间，也可能是录制时间轴上的第 14 分 14 秒。无论哪种，它都起到了“回归测试锚点”的作用：如果升级了 overay 配置，玩家可以回到同一份地图，用相同参数重新跑一遍，看是否仍在相近的时间点通关。

1.2 核心能力一览表

说明：表格里没有写死显存、帧数、内存上限，因为这些参数取决于你的电脑配置、游戏版本和已安装模组数量。更稳妥的做法是在测试过程中用 F3 和任务管理器采集本机数据。

2. 适用场景与使用边界

2.1 适合谁

这套测试思路最适合三种人。

第一种是资源包开发者。你做了一个材质包，想在多个游戏版本里同时维护默认材质和“高清覆盖层”，就需要理解 pack.mcmeta 里的 overlays 机制。通过拼好种进入固定地图，能快速检查方块纹理、天气效果、GUI 贴图是否按预期叠加。

第二种是整合包维护者。整合包通常会有多个数据包、资源包、光影包同时生效，玩家经常分不清某个效果到底来自哪里。用 overlay 测试流程可以逐层开启、逐层验证，把“哪个包改了什么”彻底排查清楚。

第三种是内容创作者和游戏策划玩家。如果你需要录制“overlay 相机”视角，即在游戏画面上叠加摄像头画面、坐标、帧数、任务进度，这套流程可以帮助你把录制参数固定下来，避免每次录出来的画面风格都不一样。

2.2 不适合谁

如果你追求的是纯原版、纯净生存体验，不希望画面有任何额外信息叠加，那么这套测试方案会显得有些“重”。它的核心目标不是还原原始游戏体验，而是把游戏过程变成可观察、可测量、可复现的测试环境。

同时，如果你在多人服务器里玩，需要特别谨慎。很多服务器有反作弊机制和客户端规则，不允许使用额外显示实体位置、结构边框、光照信息的模组。即使是你自己搭建的服务器，一旦给其他玩家分发带有 overlay 功能的客户端，也要提前说明规则，避免因为客户端不一致引发争议。

2.3 合规边界

下面这些点建议先登记到自己的检查清单里：

• 使用的资源包、模组、光影包必须来自可信来源，并查看作者的开源许可或分发许可。
• 多人服务器中，涉及玩家位置、名字、聊天的叠加显示功能，需要确保服务器规则允许，不能用来获取不公平优势。
• 录制直播内容时，如果画面里出现其他玩家的名字、语音、隐私信息，需要获得对方授权。
• 不要使用任何用于攻击他人服务器、绕过服务器验证、干扰其他玩家的技术。
• 单机测试环境下，你可以自由尝试各类 overlay 功能，但发布整合包时仍要逐项核对版权。

3. 环境准备与前置条件

3.1 操作系统与 Java

《我的世界》Java 版是跨平台的，Windows、Linux、macOS 都可以运行。但不同平台在路径处理上有些区别：

• Windows 需要注意路径分隔符和权限问题，特别是安装在 Program Files 目录时，启动器可能没有写入权限。
• Linux 需要确认系统安装的 Java 版本与游戏版本匹配。
• macOS 的文件权限检查和 Gatekeeper 校验可能会拦截第三方启动器。

Java 版本不能写死。不同游戏版本要求的 Java 版本不同，最稳妥的方式是使用启动器自带的 Java 运行时，而不是手动指定系统 Java。如果你在启动时看到UnsupportedClassVersionError，基本就是 Java 版本不对，去启动器设置里切换一个版本再试。

3.2 游戏本体与存档目录

准备一份独立的“测试存档”是非常有必要的。这样可以避免测试 overlay 配置时污染你的长期生存档。

先确认游戏目录结构。以官方启动器为例，常见的路径如下：

.minecraft/ ├── versions/ ├── resourcepacks/ │ └── my_overlay_test/ ├── saves/ │ └── overlay_test_world/ ├── mods/ └── config/

如果使用第三方启动器，这些目录可能被放在独立实例目录里，比如 Prism Launcher 的instances/xxx/.minecraft/。你只需要保证资源包、存档、模组都放在同一个游戏目录下即可。

创建测试存档时，优先用“拼好种”而不是随机种子。通过种子创建世界后，建议先跑一段脚本把存档备份下来。后续每次测试前恢复这份存档，就能保证地图结构、玩家位置、时间进度完全一致。

3.3 overlay 相关资源包与模组

overlay 在《我的世界》里不是一个菜单开关，它分散在多个功能模块中。我在这次测试里重点关注以下几种：

• 资源包 overlay：通过 pack.mcmeta 中的 overlays 字段，让一个资源包根据游戏版本自动加载不同的覆盖文件。这是官方支持的能力。
• 结构边框 overlay：通过 MiniHUD 这类模组在游戏画面上显示方块边界、结构生成区域、光照等级等信息。
• F3 调试叠加：按下 F3 后显示的坐标、朝向、帧数、内存占用、生物数量等信息。
• 录制 overlay 相机：通过 OBS 等软件把摄像头画面、文字、坐标信息叠加到游戏画面上，属于内容制作层面的 overlay。

如果你只是为了通关测试，不安装任何额外模组也能完成大部分验证。但如果你想在画面里直接看到要塞边界、末地传送门结构、区块光照等级，MiniHUD 这类模组会更直观。这里不指定具体版本，安装前先去模组平台确认是否兼容你的 Minecraft 版本。

3.4 录制与相机叠加工具

“overlay 相机”这个热词指向的是录制和直播场景。如果你需要在通关视频里叠加摄像头画面、操作提示、倒计时，可以使用 OBS Studio。它本身不修改游戏文件，只是在录制输出层叠加信息。

OBS 侧需要准备的内容：

• 游戏源：使用“显示器采集”或“游戏捕获”将《我的世界》画面接入。
• 摄像头源：把实时摄像头画面以小窗口形式叠加。
• 文本源：显示时间、坐标、当前任务。
• 浏览器源：可以用来加载自己写的网页叠加面板，方便显示动态数据。

这一段先做到“知道有这个能力”，具体的叠加参数放到第 5 章测试部分再展开。

4. 安装部署与启动方式

4.1 资源包 overlay 目录的配置方式

资源包 overlay 是官方提供的资源包能力，允许同一个资源包在不同 pack_format 下加载不同的覆盖内容。这样可以解决一个老问题：一个资源包想要同时支持多个游戏版本，但不同版本的资源文件名和格式不完全一致，硬要兼容就会导致报错或材质丢失。

pack.mcmeta 的配置方式是把 overlays 字段写成一个数组。下面是一份通用示例：

{ "pack": { "pack_format": 15, "description": "Overlay test pack" }, "overlays": [ { "directory": "overlay_v2", "formats": [16, 17, 18] } ] }

在这份配置里：

• pack_format表示资源包当前的主版本格式。
• overlays.directory指向资源包根目录下的一个子目录。
• overlays.formats表示这个子目录只在哪些 pack_format 下生效。

要注意的是，overlay 目录下的文件结构和主资源包 assets 目录结构必须一致。举个例子，如果你要在对应版本下覆盖石头的纹理，目录结构需要这样组织：

my_overlay_test/ ├── pack.mcmeta ├── assets/ │ └── minecraft/ │ └── textures/ │ └── block/ │ └── stone.png └── overlay_v2/ └── assets/ └── minecraft/ └── textures/ └── block/ └── stone.png

这样设计后，只有游戏版本匹配formats列表时，overlay_v2里的 stone.png 才会被优先加载，主目录里的 stone.png 则作为兜底版本。

4.2 通过启动器加载

大多数玩家和开发者不会手写 Java 命令去启动游戏，而是通过启动器来管理。这里以通用流程说明：

1. 把资源包文件夹放到游戏目录的resourcepacks/下。
2. 打开游戏，进入“选项 -> 资源包”。
3. 将测试资源包从“可用”列表加入“已选”列表。
4. 等待游戏重新加载资源，检查左下角是否出现资源包加载提示。
5. 如果安装了模组，记得把模组 jar 文件放入mods/目录。

需要注意：资源包名称建议用小写英文字母和下划线，不要用中文和空格。虽然中文资源包名也能用，但在日志排查和路径处理时容易出问题。

4.3 命令行启动模板

如果你不想每次手动点击启动器，可以用命令行方式启动。不过《我的世界》原版的命令行启动参数很长，并且不同版本的参数会变化。这里只给一个简化模板，实际运行时请用启动器导出的命令替换。

# 启动命令示例，实际参数需要根据游戏版本和启动器生成 "<游戏目录>/runtime/java/bin/java" \ -Xmx4G -Xms2G \ -Djava.library.path="<游戏目录>/natives" \ -cp "<游戏目录>/libraries/*:<游戏目录>/versions/1.20.1/1.20.1.jar" \ net.minecraft.client.main.Main \ --version 1.20.1 \ --username test_user \ --gameDir "<游戏目录>" \ --assetsDir "<游戏目录>/assets"

在实际使用中，更稳妥的方式是在启动器里配置好 JAVA 参数，然后使用启动器提供的日志输出。比如把-Xmx4G改成-Xmx6G，就需要注意电脑物理内存是否足够。命令行启动适合自动化测试，但排错成本比启动器高，第一次操作建议先用启动器跑通，再考虑脚本化。

5. 功能测试与效果验证

5.1 测试 1：资源包覆盖层是否生效

这个测试的目的是确认 pack.mcmeta 里的 overlays 配置被游戏正确读取。

测试步骤：

1. 在资源包主目录的assets/minecraft/textures/block/stone.png放一张红色纹理。
2. 在overlay_v2/assets/minecraft/textures/block/stone.png放一张蓝色纹理。
3. 把资源包放入 resourcepacks 并启用。
4. 在游戏里放置一块石头。
5. 如果当前游戏版本匹配 overlay_v2 的 formats，石头显示蓝色。
6. 如果当前版本不匹配，石头显示红色。
7. 如果游戏报资源包错误，说明 overlays 路径或 pack_format 有问题。

判断成功的标准很简单：石头纹理颜色与预期一致。如果看到的是原版石头纹理，说明资源包可能没有加载成功，先检查 resourcepacks 里的文件夹层级和 pack.mcmeta 是否放在根目录。

5.2 测试 2：结构边框与区块边界 overlay

如果你安装了 MiniHUD 等结构显示模组，可以进一步测试结构边框 overlay。

测试步骤：

1. 进入拼好种生成的测试存档。
2. 打开模组的配置界面，开启“Structure Bounding Box”显示。
3. 使用定位工具找到附近的结构，比如村庄、要塞、废弃矿井。
4. 观察游戏画面中是否出现半透明边框。

这个测试的重点不是“能不能显示”，而是“显示的位置和结构是否正确”。如果你在某个坐标看到了一个边界框，但实际挖掘下去并没有对应结构，那可能是资源包缓存或模组数据过期的问题。

判断是否成功：

• 边框与结构实际边界对齐。
• 在附近移动时边框不会明显抖动。
• 关闭显示开关后边框立即消失。

需要注意，结构边框 overlay 在纯原版客户端里是没有的，它依赖模组实现。如果你的测试环境是原版，这一项可以跳过。

5.3 测试 3：F3 调试信息与性能数据叠加

F3 调试界面是《我的世界》自带的信息 overlay，不需要安装任何模组。

测试步骤：

1. 进入测试存档。
2. 按一次 F3 打开调试界面。
3. 记录左上角的帧数、面向方向、坐标、内存分配。
4. 按 F3 + Q 可以查看所有调试快捷操作组合。
5. 移动角色到不同区域，观察帧数变化。

判断标准：

• F3 能正常显示坐标，例如XYZ: 12.0 / 64.0 / 33.0。
• 帧数数据在移动、加载区块时有波动。
• 内存数值能够持续更新。

如果你想让 F3 信息自动叠加到直播画面上，可以在 OBS 里通过窗口捕获截取这段区域，或者用专门的文本插件读取游戏日志。不过 F3 界面会遮挡大量画面，建议只在调试阶段开启，正式录制时关闭。

5.4 测试 4：通关流程验证

这次测试的最终目标是“14:14 进入终末之诗”。完整通关流程可以拆成几个子步骤：

1. 合成末影之眼。
2. 投掷末影之眼，记录飞行方向，定位要塞。
3. 进入要塞，找到末地传送门房间。
4. 按照拼好种生成的地图信息，使用末影之眼填充传送门框架。
5. 跳入传送门，进入末地。
6. 击杀末影龙，触发传送门，进入终末之诗界面。

每一步都可以记录一个时间节点。比如从创造世界到首次投掷末影之眼用了 2 分钟，从定位到进入末地用了 5 分钟，击杀末影龙用了 3 分钟。把这些时间节点从 F3 调试面板的时间戳或录制软件的时间轴里记录下来，就能判断整个流程是否稳定在 14:14 附近。

这里要特别说明：通关时间受装备、操作水平、地图结构影响很大。如果拼好种生成的种子天然要塞距离出生点很近，通关时间自然更短。所以，如果这次测试没有刚好到达 14:14，不要纠结于“必须精确复现时间”，而是关注“每次运行的时间波动范围是否合理”。

判断成功的标准：

• 成功进入终末之诗画面。
• 资源包和 overlay 配置在末地场景中依然生效。
• 整轮测试没有出现崩溃或存档损坏。

5.5 测试 5：overlay 相机与录制叠加

如果你想把游戏画面和摄像头画面同时录制到最终视频里，可以使用 OBS 的“叠加”方式。这个环节本质上是测试 overlay 在视频采集链路上是否正常。

测试步骤：

1. 打开 OBS，新建场景。
2. 添加“游戏捕获”源，选择《我的世界》窗口。
3. 添加“视频捕获设备”源，选择摄像头。
4. 将摄像头源缩小，拖到画面右下角或左上角。
5. 添加“文本”源，显示当前时间、测试轮数、坐标信息。
6. 点击开始录制，跑一段通关流程，检查画面叠加是否正常。

判断标准：

• 游戏画面与实际操作延迟保持稳定。
• 摄像头画面清晰，不遮挡关键 UI。
• 文本信息没有乱码，且位置不会被游戏内元素覆盖。
• 如果是 14:14 这个时间基准点，OBS 时间轴里能看到完整过程。

如果你需要更复杂的动态数据叠加，比如实时显示“当前 FPS”“末影之眼数量”“坐标”，可以写一个基于网页的 overlay 面板，再通过 OBS 浏览器源加载。这属于进阶玩法，后续可以单独扩展。

6. 接口、脚本与批量任务

6.1 MC 的资源包接口本质

《我的世界》本身没有像 Web 服务那样的 HTTP API。它和外部程序交互的“接口”主要是文件系统和协议：

• 资源包与数据包通过文件目录结构加载。
• 存档通过.minecraft/saves目录读写。
• 模组通过mods/目录加载。
• 服务端可以通过 RCON 协议执行远程指令，但单机测试不一定需要。

这意味着批量任务更适合用 Python、Shell 脚本去操作文件，而不是直接调用游戏接口。

6.2 pack.mcmeta overlays 配置示例

再给一份适合实际测试的 JSON 配置。假设你的资源包主打的是“低配兼容”，要在旧版本用低清纹理，新版本用高清纹理，可以这样配置：

{ "pack": { "pack_format": 22, "description": "Minecraft overlay test pack - compatible mode" }, "overlays": [ { "directory": "overlay_low", "formats": [15, 16, 17] }, { "directory": "overlay_high", "formats": [18, 19, 20, 21, 22] } ] }

注意：pack_format 的数字需要和你的游戏版本对应。不要把版本写错，否则资源包会被判定为“不兼容”。如果不确定当前版本的 pack_format，可以打开游戏日志，找资源包安装提示。

6.3 批量校验脚本

资源包数量多了以后，手动检查每个包是否包含 overlay 目录会非常耗时。可以用 Python 写一个批量校验脚本，扫描指定目录下所有资源包，输出结构报告。

import json from pathlib import Path def check_overlay(pack_dir: Path): meta_path = pack_dir / "pack.mcmeta" if not meta_path.exists(): return { "name": pack_dir.name, "valid": False, "reason": "pack.mcmeta not found" } try: with open(meta_path, "r", encoding="utf-8") as f: meta = json.load(f) except json.JSONDecodeError as e: return { "name": pack_dir.name, "valid": False, "reason": f"invalid json: {e}" } overlays = meta.get("overlays", []) overlay_dirs = [] for overlay in overlays: directory = overlay.get("directory") if directory: overlay_path = pack_dir / directory exists = overlay_path.exists() overlay_dirs.append({ "directory": directory, "exists": exists }) return { "name": pack_dir.name, "valid": True, "overlay_count": len(overlay_dirs), "overlay_dirs": overlay_dirs } def scan_resources_packs(root: Path): result = [] for pack_dir in root.iterdir(): if pack_dir.is_dir(): result.append(check_overlay(pack_dir)) return result if __name__ == "__main__": packs_root = Path("./resourcepacks") report = scan_resources_packs(packs_root) for item in report: print(json.dumps(item, ensure_ascii=False, indent=2))

这个脚本主要做三件事：

1. 遍历 resourcepacks 目录下的所有资源包。
2. 检查每个资源包是否有合法的 pack.mcmeta。
3. 解析 overlays 列表，检查 overlay 目录是否存在。

你可以把它保存为check_overlay.py，放在游戏根目录旁运行。实际使用时要调整packs_root路径。

6.4 存档批量验证

如果你要做多轮回归测试，建议写一个存档备份脚本。每次测试前把干净存档恢复到 saves 目录，测试后把结果保存到独立目录。

import shutil from datetime import datetime from pathlib import Path save_src = Path("./saves/overlay_test_world") backup_root = Path("./backups") def backup_world(): backup_root.mkdir(exist_ok=True) session = datetime.now().strftime("%Y%m%d_%H%M%S") dst = backup_root / f"overlay_test_{session}" shutil.copytree(save_src, dst) print(f"backup created: {dst}") def restore_world(target): save_src_unlink = Path("./saves/overlay_test_world") if save_src_unlink.exists(): shutil.rmtree(save_src_unlink) shutil.copytree(target, save_src_unlink) print(f"restored from: {target}") if __name__ == "__main__": backup_world()

这里没有覆盖真实存档目录，因为不同启动器的存档路径可能不一样。你只需把save_src改成你的实际路径就能跑。真正的批量测试流程可以是：

备份当前存档 -> 复制干净存档 -> 启动游戏 -> 运行测试 -> 截图保存结果 -> 退出游戏 -> 还原备份 -> 切换下一组 overlay 配置

这样就形成可循环的批量任务。

7. 资源占用与性能观察

7.1 在哪里看性能

《我的世界》不像大型 3A 游戏那样自带完整统计面板，最直接的性能观察入口是 F3 调试界面。打开 F3 后可以看到：

• FPS 区域：当前帧数，以及最小和最大帧数参考。
• 内存区域：已分配内存、已用内存、可用内存。
• 生物和实体数量：当前区块里加载了多少实体。
• 渲染信息：当前已加载区块数、渲染距离设置。

另外，Windows 任务管理器、Linux 的top、macOS 的活动监视器也可以看 Java 进程的 CPU 和内存占用。但要注意，Java 进程的内存占用通常高于游戏实际使用，因为 JVM 会预分配一部分内存池。

7.2 影响开销的因素

overlay 功能本身开销不大，但它叠加在游戏渲染链路里，受以下因素影响：

• 资源包纹理分辨率：如果 overlay 目录里放的是 512x 或 1024x 高清纹理，显存和内存占用会明显上升。
• 结构边框数量：在要塞、村庄、末地传送门附近开启结构边界显示，会额外绘制大量线段。
• 区块渲染距离：渲染距离越大，F3 里的帧数波动越明显。
• 录制软件叠加：OBS 同时编码游戏画面和摄像头画面，会占用 CPU 或 GPU。
• 粒子与实体积聚：末影龙战斗阶段，大量末影粒子、水晶爆炸效果会拖慢帧数。

7.3 降低开销的方法

如果测试过程中帧数下降明显，优先按顺序调整：

1. 在 F3 界面把渲染距离降低 2-4 个等级。
2. 关闭模组里的实体边框显示，只保留需要的结构类型。
3. 把资源包纹理降到 32x 或 64x 测试版本。
4. 在 OBS 中把游戏画面录制帧率限制到 30 FPS 或 60 FPS。
5. 关闭光影包。overlay 测试阶段不是非要开光影。
6. 给 JVM 增加内存，但不要超过物理内存的一半。

显存占用这一项，我只能提醒你通过显卡驱动面板或任务管理器观察，不能替你写一个确定的数字。不同版本、不同资源包配置差异很大。更稳妥的测试方法是用同一台机器、同一份存档，分别跑“overlay 开启”和“overlay 关闭”两组数据，对比帧数和内存差异。

8. 常见问题与排查方法

上面这组表格是通用排查思路。具体到你本地环境时，最有效的方法是看日志，而不是只看画面。启动器一般会把最新日志打印出来或保存到 logs 目录。日志里出现Unable to load resource、Error: no file found这类关键词时，基本可以定位到资源包问题；出现OutOfMemoryError时，内存配置需要调整。

9. 最佳实践与使用建议

9.1 目录管理

建议把所有测试相关资源集中到清晰目录里。比如：

minecraft_project/ ├── resourcepacks/ │ ├── my_overlay_test/ │ └── my_overlay_test_low/ ├── backups/ ├── saves/ │ └── overlay_test_world/ ├── scripts/ │ ├── check_overlay.py │ └── backup_world.py └── recordings/

这样每次测试之前，你只需执行备份脚本，然后启动游戏，后续导出截图和录像是完全分开的。

9.2 版本锁定

《我的世界》的模组和资源包对版本非常敏感。不要在一个测试实例里混用不同版本的光影包和资源包，也不要在升级游戏版本后继续沿用旧存档，除非备份独立。

更稳妥的做法是：

• 为不同版本建不同实例。
• 每个实例的 mods、config、resourcepacks 完全隔离。
• 在资源包版本里把 pack_format 写清楚。

9.3 最小配置优先

第一次做 overlay 测试时，不要把 20 个模组、5 个资源包、光影包一下子全开进去。先跑最小配置：

• 原版资源包 + 一个自建 overlay 测试包。
• 一个需要的结构显示模组。
• 关闭光影包。
• 渲染距离设为 12 或 16。

跑通之后再逐步添加组件。出现问题的时候，你才能快速判断是资源包、模组还是光影的问题。

9.4 回归验证思路

对于通关流程测试，每次修改 overlay 配置后，都建议跑一次回归步骤：

1. 恢复拼好种对应的干净存档。
2. 记录当前游戏时间，作为测试起始时间。
3. 按照第 5 章的测试顺序逐项验证。
4. 记录各阶段耗时。
5. 对比是否仍在 14:14 时间点附近进入终末之诗。

如果时间差过大，说明新增配置可能影响了游戏性能或流程，需要进一步分析。

9.5 合规提醒

最后再强调一次：在多人服务器中使用任何 overlay 相关功能前，先阅读服务器规则；在发布整合包或录屏时，确认资源包和模组的授权允许二次分发；涉及其他玩家信息时，必须保护隐私。单机环境是最自由的，但自由不等于可以拿未授权素材做商业用途。

10. 总结与下一步

这个测试案例最值得尝试的点是：把“玩《我的世界》”这件事从随机过程变成了可复现的测试过程。拼好种保证了地图一致，overlay 配置保证了画面信息一致，14:14 进入终末之诗则提供了一个可对比的回归基准。

最先应该验证的功能是 pack.mcmeta 里的 overlays 资源包覆盖层。因为它最简单、最贴近“接口”概念，只要一个 JSON 文件和两张不同颜色的纹理图就能确认游戏是否读取了你写的目录配置。这一步跑通了，后面的结构边框、F3 叠加、OBS 相机叠加才有意义。

最容易踩的坑有三个：一是资源包目录层级不对，导致游戏完全读取不到；二是 overlay 的 formats 列表和当前游戏版本不匹配，导致覆盖层被静默忽略；三是在多人服务器里使用 mod 类 overlay 功能，被服务端当作异常客户端拦截。

下一步可以继续扩展的方向包括：把检查脚本接入 CI，每次修改资源包后自动校验目录结构；用 Python 脚本批量生成多版本 overlay 配置；把 OBS 叠加面板做成网页，实时显示通关流程中的坐标、时间和末影之眼数量。这样你就不再是“第 25 天玩我的世界”，而是拥有了一套自己的 Minecraft 测试工程。建议把这套流程保存成项目配置，下次换一台机器或换一个游戏版本时，直接用备份脚本恢复整个测试环境。