Minecraft 服务器意外生成新世界的修复方法

上传存档或重启后出现全新地形，并不等于原世界已经被删除。更常见的情况是服务器找不到目标目录、配置指向另一个名称，或因加载失败而创建了新目录。此时最重要的是立即停止写入，保留两个世界和第一次异常日志。

立即停服并保存现场

在控制台正常执行 stop，确认进程退出。不要让玩家继续在新世界游玩，否则会形成无法直接合并的第二条进度。把原世界、新生成世界、server.properties 和 logs/latest.log 分别复制到活动目录之外，并记录目录名称、体积、修改时间和故障前操作。

不要先删除新目录，它的名称正好说明服务器试图加载什么。若面板有崩溃自动重启功能，诊断期间先关闭，避免反复启动改变现场。

找到真正的世界根目录

在原存档中找到 level.dat，直接包含它的目录才是世界根。server/london/london/level.dat 代表多套了一层；未解压 ZIP 也不能直接加载。比较新旧目录大小：旁边出现一个很小、时间很新的目录，通常指向名称或路径错误，而非原世界立刻损坏。

不要只在两个世界之间复制 level.dat。区块、实体、兴趣点、玩家和维度数据必须保持一致。还要确认大文件上传和服务器端解压没有中途中断。

核对 level-name 与面板设置

停服时检查活动的 server.properties：

level-name=mapmc-london

值应与原世界目录逐字一致，不加引号和扩展名，Linux 注意大小写。主机面板可能另有“世界名称”字段并在启动时覆盖文件，保存后重新查看最终值。若新目录叫 world，通常说明服务器仍在使用默认值；若新目录与目标同名，则继续检查嵌套、权限和工作目录。

确认真正运行的实例目录

同一面板可能存在多个实例、配置档或容器卷。文件上传成功不代表当前 Java 进程会读取它。查看启动命令、JAR 路径、实例名称及日志开头，确认运行目录就是刚才编辑的位置。

自建服务器还要检查 systemd 或容器的工作目录和文件权限；部署脚本、同步任务或还原计划也可能在启动时覆盖文件。不要把世界盲目复制到所有目录，而要先定位唯一运行进程。

从第一条加载错误开始读日志

在 latest.log 中搜索目标世界名、数据版本、session lock、权限、缺失模组、数据包以及读取 level.dat 或区块时的异常。服务器最终出现“就绪”不代表加载正确，它可能在原世界失败后成功生成了空白世界。

保存第一条相关错误和完整时间，不要连续重启让日志被覆盖。若提示世界来自更高数据版本，不要用旧版打开唯一副本；恢复匹配运行环境，再在复制品上测试升级。

只对一份副本做修正测试

复制原世界并取一个简单测试名，只修正有证据的问题：去掉一层包装目录、完成上传、调整 level-name、补回依赖，或让进程使用正确根目录。测试期间保持白名单。

启动后确认日志明确加载测试世界，再检查出生点、已知建筑、下界与末地、玩家背包及数据包。正常停服、重启并验证小改动仍在。仅凭种子或出生点地形相似不能证明是同一个世界。

按证据选择恢复分支

• 名称不匹配：保留两份备份后修正 level-name。
• 多套目录：把包含 level.dat 的根目录放到预期层级。
• 运行了错误实例：修正进程或上传到该实例的文档化根目录。
• 依赖缺失：先复现兼容服务端环境。
• 存档确实损坏：以新目录名恢复已验证备份，并保留损坏副本。

不要用“删掉新世界逼它识别旧世界”的办法。服务器往往只会再次生成配置所指向的目录，同时让诊断证据消失。

防止再次静默切换

把自动备份放在活动目录之外，并定期演练恢复。记录当前 level-name、服务器根目录、版本、加载器、模组和面板实例。迁移或升级后，固定执行一次私密启动、地标检查、正常停服和再次启动。

安全顺序始终是：停服、复制、找根目录、核对名称、确认实例、读第一条错误，再测试副本。多数可恢复的“世界丢失”都能由此定位为明确配置问题。