兼容、重构与技术债

1.13 的 Flattening 更新让所有数字方块 ID 变成命名空间标识符。这是一次巨大的重构，代价是：所有旧版本 Mod 失效，玩家的世界需要通过 DataFixerUpper 转换才能打开。

为什么 Mojang 不能"把代码重写一遍"？为什么每次大版本更新 Mod 都要重新适配？为什么 Quasi-Connectivity 这个明显的 Bug 不能修复？答案是：兼容成本。

本章要回答的核心问题是：

为什么 Minecraft 不能"推倒重来"？兼容成本体现在哪些层次？技术债是怎样产生的，又如何影响开发决策？

我们会看到，兼容成本不是单一维度的"代码质量"问题，而是分布在多个层次：存档兼容（玩家的世界必须能在新版本打开）、协议兼容（服务器和客户端必须能通信）、Mod 兼容（社区工具必须能继续工作）、玩法兼容（历史行为已经成为玩家依赖的"特性"）。这些兼容需求不是"技术债"的借口，而是长期运营游戏的必然约束。

技术债不是"代码写得烂"，而是"早期决策在后续发展中暴露的局限 + 社区已经依赖的历史行为"。某些"债"可以通过重构偿还（如 Flattening、组件化），某些"债"必须永久保留（如 Quasi-Connectivity），某些"债"只能通过社区工具缓解（如 Sodium、Paper）。

1存档兼容：玩家的世界比引擎活得久

Minecraft 最核心的兼容需求是：玩家的世界必须能在新版本打开。

1.1存档是玩家的时间投入

与关卡游戏不同，Minecraft 的存档代表玩家数月甚至数年的建造、探索、收集：

• 一座城市，花了 500 小时建造；
• 一个红石计算机，设计了 3 个月；
• 一组自动农场，调试了数百次；
• 一箱子附魔装备，打了几十小时怪。

如果新版本不能打开旧存档，这些时间投入全部作废。

这不是"缓存失效"，而是"家被拆了"。

1.2存档格式的演化

Minecraft 的存档格式经历了多次重大变化：

Alpha / Beta 早期：

• 每个 Chunk 一个文件（.dat）；
• 大量小文件导致文件系统性能问题。

Beta 1.3 (2011)：McRegion：

• 将 32×32 个 Chunk 合并到一个 Region 文件（.mcr）；
• 减少文件数量，提升 I/O 性能。

1.2.1 (2012)：Anvil：

• 改进的 Region 格式（.mca）；
• 支持更高的世界高度（256 格）；
• 至今仍在使用。¹

1.13 (2018)：Flattening：

• 数字方块 ID（如 1 代表石头）改为命名空间标识符（minecraft:stone）；
• 方块状态（BlockState）取代元数据（Metadata）；
• 旧存档需要通过 DataFixerUpper 转换。²

1.18 (2021)：世界高度扩展：

• 世界高度从 0-255 扩展到 -64 至 319；
• 旧区块底部补深板岩，顶部补空气。³

1.20.5 (2024)：物品组件化：

• 物品 NBT 改为结构化的组件（Data Components）；
• 旧物品的 NBT 需要迁移到新格式。⁴

1.3DataFixerUpper：迁移工具

Mojang 开发了 DataFixerUpper (DFU)，一个开源库，用于在版本间迁移存档数据。⁵

工作原理：

1. 版本号追踪：每个存档记录创建时的版本号；
2. 迁移规则链：从旧版本到新版本的每一步迁移规则；
3. 自动应用：打开旧存档时，DFU 自动应用所有中间迁移。

示例：Flattening 迁移

旧格式（1.12）：

{
  "id": 1,
  "Damage": 0
}

新格式（1.13+）：

{
  "Name": "minecraft:stone"
}

DFU 自动将数字 ID 和元数据转换为命名空间标识符和方块状态。

1.4兼容的代价

存档兼容的代价是巨大的：

无法删除历史格式：

• DFU 必须保留从最早版本到当前版本的所有迁移规则；
• 即使某个中间格式已经过时 10 年，迁移代码仍然需要维护。

迁移时间：

• 大型存档（数 GB）的迁移可能需要数小时；
• 1.13 Flattening 时，许多玩家报告迁移时间超过 1 小时。

无法"重新设计"世界格式：

• 如果想改用完全不同的存储方式（如图数据库），必须提供从 Anvil 的完整迁移路径；
• 否则所有旧存档无法使用。

第 02 章《存储与序列化》详细讨论了存档格式的演化。

2协议兼容：服务器与客户端的版本地狱

Minecraft 的网络协议没有官方的向后兼容承诺，但社区工具（如 ViaVersion）让跨版本联机成为可能。

2.1协议的演化

每个 Minecraft 版本都有一个 Protocol Version：

协议不兼容的后果：

不同 Protocol Version 的客户端和服务器无法直接通信。

2.2ViaVersion：跨版本桥接

ViaVersion 是一个服务器插件，允许不同版本的客户端连接到同一个服务器。⁶

工作原理：

1. 服务器运行在某个版本（如 1.21.4）；
2. ViaVersion 拦截客户端的连接请求；
3. 根据客户端的 Protocol Version，动态转换 Packet；
4. 客户端以为连接的是自己版本的服务器。

示例：

• 服务器：1.21.4 (Protocol 769)
• 客户端 A：1.20.1 (Protocol 763)
• 客户端 B：1.21.0 (Protocol 767)
• 客户端 C：1.21.4 (Protocol 769)

ViaVersion 让三个客户端都能连接到同一个服务器。

2.3协议兼容的局限

ViaVersion 不是万能的：

新内容无法向后兼容：

• 如果 1.21 添加了新方块，1.20 客户端看到的是"未知方块"；
• 如果 1.21 添加了新实体，1.20 客户端可能看不到。

Packet 结构变化：

• 每个版本的 Packet 格式可能不同（字段增加、删除、重排）；
• ViaVersion 需要手动维护每个版本的转换规则；
• 每次 Minecraft 更新，ViaVersion 都需要适配。

性能开销：

• Packet 转换需要 CPU 和内存；
• 大型服务器（如 Hypixel）必须权衡兼容性和性能。

2.4为什么 Mojang 不提供官方兼容？

官方立场：协议是"内部实现细节"，不保证向后兼容。

原因：

1. 快速迭代：如果协议需要向后兼容，每次修改都要考虑历史版本，开发速度会变慢；
2. 安全性：旧协议可能有安全漏洞，强制升级可以修复；
3. 社区已经解决：ViaVersion 等工具已经满足需求。

代价：

• 服务器运营者必须选择：锁定版本（失去新内容），或强制升级（失去旧版本玩家）；
• 社区工具（ViaVersion）成为"民间官方实现"。

第 10 章《网络架构与状态同步》详细讨论了协议的设计。

3Mod 兼容：为什么每次大版本更新 Mod 都要重写

Minecraft 没有官方 Mod API，社区 Mod 依赖字节码注入和反射，因此每次大版本更新，Mod 都需要重新适配。

3.1Mod 兼容的三个层次

1. 字节码兼容

Mod Loader（Forge / Fabric）通过 Mixin 在运行时修改 Minecraft 的字节码：

@Mixin(MinecraftServer.class)
public class MixinMinecraftServer {
  @Inject(method = "tick", at = @At("HEAD"))
  private void onTick(CallbackInfo ci) {
    // 自定义逻辑
  }
}

问题：

• 如果 Minecraft 重命名了 MinecraftServer 类或 tick 方法，Mixin 失效；
• 如果 tick 方法的实现逻辑改变，注入点可能不再存在。

1.13 Flattening 的影响：

• 大量类和方法重命名；
• 方块和物品的注册系统完全重写；
• 几乎所有 1.12 的 Mod 无法在 1.13 运行。

2. 映射兼容（Mapping）

Minecraft 的发布版本使用混淆的类名（如 a, b, c），Mod 开发需要反混淆映射（Mapping）：

MCP（Mod Coder Pack）：

• 早期的映射工具；
• 手动维护类名和方法名。

Yarn / Mojmap：

• 社区维护的映射（Yarn）；
• 官方映射（Mojmap，1.16.5+ 提供）。

问题：

• 每个版本的映射不同；
• Mod 需要在新映射上重新编译。

3. API 兼容

Forge / Fabric 提供 API（如事件系统、注册表），但这些 API 也会随版本演化：

示例：Forge 的 Registry 系统

1.12：

GameRegistry.register(new ItemStack(myItem));

1.13+：

event.getRegistry().register(myItem);

API 变化意味着 Mod 需要修改代码。

3.2为什么 Mojang 不提供稳定的 Mod API？

历史尝试：

• Mojang 曾计划开发官方 Mod API；
• 2012 年收购 Bukkit 团队，希望将其整合到 Java Edition；
• 2014 年 Bukkit DMCA 危机后，计划搁置。

当前状态：

• Data Pack 和 Resource Pack 提供有限的官方扩展能力；
• 但无法替代 Mod 的能力（添加新方块、实体、维度）。

原因：

1. 开发成本：稳定的 API 需要大量设计和维护；
2. 限制内部重构：一旦提供 API，内部实现必须保持兼容；
3. 社区已经解决：Forge / Fabric 已经满足需求。

代价：

• Mod 作者每次大版本更新都要重新适配；
• 玩家在新版本发布后，常常需要等待数周甚至数月才能使用 Mod。

第 14 章《Mod、Mixin 与加载器》详细讨论了 Mod 的工作原理。

4玩法兼容：历史 Bug 变成特性

某些 Minecraft 的"Bug"已经成为玩家依赖的"特性"，修复它们会破坏现有玩法。

4.1Quasi-Connectivity：不能修复的 Bug

Quasi-Connectivity (QC) 是 Java Edition 红石系统的历史行为：

• 活塞、投掷器等方块会检查上方一格是否有红石信号；
• 这是一个 Bug（检查函数多看了一格）；
• 但玩家已经依赖它设计了大量红石机器（BUD、门、电梯）。

MC-108：Works as Intended

2012 年，玩家在 Bug Tracker 提交 QC 为 Bug，Mojang 将其标记为 Works as Intended (WAI)。⁷

这不是"承认 Bug 是正确的"，而是承认社区已经依赖这个行为，修复会破坏太多东西。

如果修复 QC：

• 成千上万的红石机器失效；
• 教程、Wiki、视频全部过时；
• 玩家需要重新学习红石。

Mojang 的策略：

• 保留 QC；
• 在新方块（如观察者）中不引入 QC；
• 让玩家逐渐迁移到更"正确"的设计。

4.2其他历史行为

1. 实体碰撞与推动

• TNT 矿车的碰撞箱在某些情况下不正确；
• 玩家利用这个特性设计"TNT 炮"；
• 修复会破坏这些设计。

2. 刷怪机制

• 某些刷怪机依赖"边界情况"（如特定光照、区块边界）；
• 修改刷怪算法会让这些机器失效。

3. 物品复制 Bug

• 早期某些 Bug 允许物品复制；
• 虽然是明显的 Bug，但某些服务器依赖它设计经济系统；
• 修复后，服务器需要调整规则。

4.3兼容 vs 正确

核心矛盾：

工程上的"正确"与玩家依赖的"行为"冲突时，Minecraft 选择兼容。

判断标准：

1. 行为是否稳定、可复现？ → 如果是，玩家会依赖它。
2. 修复会破坏多少现有内容？ → 如果太多，成本太高。
3. 是否有替代方案？ → 如果有，可以逐渐迁移。

结果：

• 某些 Bug 永久保留（如 QC）；
• 某些 Bug 通过新机制替代（如观察者）；
• 某些 Bug 在不破坏现有玩法的前提下修复。

第 08 章《红石与更新顺序》详细讨论了 QC 的技术原理。

5重构窗口：何时可以偿还技术债

虽然兼容成本很高,但 Minecraft 仍然进行了几次重大重构。这些重构选择在"窗口"打开时进行。

5.1重构窗口的条件

什么是"重构窗口"？

当现有设计无法支撑下一阶段的玩法或性能需求，且有明确的迁移路径时，重构窗口打开。

三个条件：

1. 旧设计已经成为瓶颈：不重构，新功能无法实现；
2. 社区已经准备好：工具链（Mod Loader、映射）可以适配；
3. 有完整的迁移路径：旧数据可以自动转换。

5.2几次重大重构

1. Anvil 格式 (1.2.1, 2012)

问题：

• 早期每个 Chunk 一个文件，导致大量小文件；
• 文件系统性能瓶颈。

窗口：

• 无限世界已经成为核心玩法；
• 需要更高效的存储格式。

迁移路径：

• 自动将旧 Chunk 合并到 Region 文件；
• 玩家无需手动操作。

2. Flattening (1.13, 2018)

问题：

• 数字方块 ID 用尽（4096 个限制）；
• 元数据（4 bit）不够用；
• Data Pack 需要命名空间标识符。

窗口：

• Data Pack 系统需要可读的方块名；
• Mod 需要更灵活的 ID 系统。

迁移路径：

• DataFixerUpper 自动转换旧存档；
• Mod Loader 更新映射。

代价：

• 几乎所有 1.12 Mod 无法在 1.13 运行；
• 玩家需要等待 Mod 更新。

3. 世界高度扩展 (1.18, 2021)

问题：

• 世界高度 256 格限制了山脉和洞穴设计。

窗口：

• Caves & Cliffs 更新需要更深的洞穴；
• 世界生成算法重写。

迁移路径：

• 旧区块底部补深板岩，顶部补空气；
• 新区块使用新生成算法。

4. 物品组件化 (1.20.5, 2024)

问题：

• 物品 NBT 是非结构化的键值对，难以维护；
• 跨平台同步（Java / Bedrock）需要统一格式。

窗口：

• Data Pack 需要更清晰的物品数据模型；
• 新物品类型（如 Bundle）需要更复杂的数据。

迁移路径：

• DataFixerUpper 自动转换旧物品 NBT；
• 新物品使用结构化组件。

5.3重构的代价

即使在"窗口"内重构，代价仍然很高：

开发成本：

• DataFixerUpper 需要为每个版本编写迁移规则；
• 测试所有可能的旧数据格式。

社区成本：

• Mod 作者需要重写代码；
• 玩家需要等待 Mod 更新；
• 服务器需要停机迁移存档。

文档成本：

• Wiki 需要更新；
• 教程需要重新录制；
• 社区需要重新学习。

结论：

重构是必要的，但必须谨慎选择时机。只有当"不重构的成本"超过"重构的成本"时，窗口才会打开。

6社区工具：民间官方实现

Minecraft 的某些"技术债"不是由 Mojang 偿还,而是由社区工具承担。

6.1Sodium / Lithium / Iris：客户端优化

Sodium：

• 重写渲染引擎，大幅提升帧率；
• 不改变游戏玩法，只优化渲染性能；
• 成为许多玩家的"默认选择"。

Lithium：

• 优化服务器端性能（AI、物理、区块加载）；
• 保持与原版行为兼容（不改变 Redstone 时序）。

Iris：

• 光影 Mod，兼容 OptiFine 光影包；
• 基于 Sodium，性能更好。

为什么 Mojang 不直接采用？

1. 维护成本：这些 Mod 的代码需要持续维护；
2. 兼容性风险：优化可能在某些硬件上不稳定；
3. 社区已经解决：玩家可以选择安装。

6.2Paper / Spigot / Folia：服务器优化

Paper：

• 优化服务器性能（Entity Tick、Chunk Loading）；
• 提供配置选项（可能改变玩法）；
• 大型服务器的"默认选择"。

Folia：

• 区域化多线程服务器（2023）；
• 将世界分成多个独立区域，并行处理；
• 实验性，API 不稳定。

为什么 Mojang 不直接采用？

1. 玩法变化：Paper 的某些优化会改变 Redstone 时序、刷怪机制；
2. 配置复杂：需要服务器管理员调优；
3. 社区已经解决：服务器可以选择安装。

6.3ViaVersion：协议兼容

• 让不同版本客户端连接到同一服务器；
• Mojang 没有提供官方跨版本支持；
• ViaVersion 成为"民间标准"。

6.4为什么社区工具是"必要"的？

核心观点：

这些工具不是"锦上添花"，而是 Minecraft 完整产品的一部分。

理由：

1. Mojang 无法满足所有需求：性能优化、跨版本兼容、高级功能；
2. 社区工具可以快速迭代：不需要等待官方更新；
3. 玩家可以选择：不同需求（原版 vs 优化 vs 跨版本）。

Minecraft 的产品定义：

Minecraft = 官方客户端/服务器 + Mod Loader + 社区工具 + Wiki

没有社区工具，Minecraft 只是"一个能跑的游戏"；有了社区工具，Minecraft 才是"一个可以长期居住的世界"。

第 15 章《插件、服务端软件与规模化》详细讨论了服务器优化。

7技术债的本质

技术债不是"代码写得烂"。

技术债是：

1. 早期决策在后续发展中暴露的局限：

   • 数字方块 ID 在 Alpha 够用，但在 1.13 不够用；
   • 单线程 Tick 在 Beta 够用，但在大型服务器不够用。

2. 向后兼容的必然结果：

   • 保留旧存档格式 → DFU 越来越复杂；
   • 保留历史行为（QC）→ 内部实现无法优化。

3. 社区依赖的历史行为：

   • Quasi-Connectivity 本是 Bug，但已成为"特性"；
   • 协议本是"内部细节"，但已成为 ViaVersion 的"API"。

技术债的三种结局：

核心认识：

技术债不是"失败"，而是长期运营游戏的必然约束。关键不是"消除所有债"，而是识别哪些债必须偿还，哪些债必须保留，哪些债可以由社区承担。

8这一章留下什么

从存档格式迁移、协议版本兼容到 Mod 适配、历史行为保留，Minecraft 的兼容成本体现在多个层次，技术债不是"代码写得烂"，而是长期运营的必然结果。

Minecraft 的兼容成本分布在四个层次：存档兼容（玩家的世界必须能在新版本打开，DataFixerUpper 维护从最早版本到当前版本的所有迁移规则）、协议兼容（不同版本的客户端和服务器无法直接通信，ViaVersion 等工具提供跨版本桥接，但需要持续适配每个新版本）、Mod 兼容（Mod 依赖字节码注入和反射，每次大版本更新都需要重新适配，1.13 Flattening 让几乎所有 1.12 Mod 失效）、玩法兼容（某些 Bug 已经成为玩家依赖的"特性"，如 Quasi-Connectivity，修复会破坏大量红石机器和教程）。

Minecraft 进行了几次重大重构（Anvil 格式、Flattening、世界高度扩展、物品组件化），但每次重构都需要满足三个条件：旧设计已经成为瓶颈、社区工具链准备好适配、有完整的迁移路径。即使在"重构窗口"内，代价仍然很高：开发成本（DataFixerUpper 需要为每个版本编写迁移规则）、社区成本（Mod 作者需要重写代码、玩家需要等待 Mod 更新）、文档成本（Wiki 和教程需要更新）。

某些技术债不是由 Mojang 偿还，而是由社区工具承担：Sodium / Lithium / Iris 优化客户端性能，Paper / Folia 优化服务器性能，ViaVersion 提供跨版本兼容。这些工具不是"锦上添花"，而是 Minecraft 完整产品的一部分。没有社区工具，Minecraft 只是"一个能跑的游戏"；有了社区工具，Minecraft 才是"一个可以长期居住的世界"。

对爱好者来说，"Minecraft 为什么不修复这个 Bug"往往不是"Mojang 不愿意"，而是"修复会破坏太多东西"。Quasi-Connectivity、Redstone 时序、刷怪机制等历史行为已经成为玩家依赖的"特性"，修复它们会让成千上万的机器失效、教程过时、Wiki 需要重写。存档兼容是 Minecraft 的核心承诺：你的世界必须能在新版本打开，这个承诺限制了"推倒重来"的可能性。社区工具（Sodium、Paper、ViaVersion）不是"可选的增强"，而是完整体验的一部分。

对开发者来说，能抄走的是：重构窗口模型（只有当"不重构的成本"超过"重构的成本"时才重构），兼容高于正确的判断标准（当历史行为已经被广泛依赖时，修复 = 破坏），迁移工具的必要性（如 DataFixerUpper，维护版本间的迁移规则链），社区工具的角色（某些"债"可以由社区承担，而不必由官方偿还）。不能照抄的是：Minecraft 的具体迁移规则、ViaVersion 的协议转换逻辑、Paper 的优化补丁。真正值得继承的是：向后兼容不是"可选特性"，而是长期运营游戏的核心承诺；技术债不是"代码烂"，而是"早期决策 + 社区依赖"的必然结果；识别哪些债必须偿还、哪些债必须保留、哪些债可以由社区承担；不要假设"推倒重来"比"逐步重构"更便宜——迁移成本往往被低估。