卷三 · 技术实现

站在一座山顶向远处看，脚边的水正在流动，村民沿道路行走，红石机器按自己的节奏工作，地下还有熔炉、漏斗和作物继续改变状态。如果这是多人服务器，另一个玩家可能正在几公里外挖矿。

对玩家来说，这些事情都发生在同一个 Minecraft 世界里。

但机器并没有维护一个完整、连续、同时运转的“世界对象”。远处的区块可能根本不在内存里；已经加载的区块也未必参与模拟；光照、流体、实体、红石和植物生长并不共享一套统一的物理规则；服务器保存的是权威状态，客户端看到的却还要经过网格生成、渲染、声音、粒子和网络同步。一个看似连续的世界，实际上由许多不同的数据结构、更新机制和时间尺度共同维持。

卷三要研究的就是这件事：

Minecraft 怎样把一个可以修改、保存、持续运行、跨网络共享，并且十多年后仍能继续升级的世界真正做出来？

1一个世界不是一个系统

如果只看玩家体验，很容易把 Minecraft 想象成一台完整运行的世界模拟器。进入实现以后，这种直觉很快就会失效。

方块首先是数据。一个位置上保存的不是“泥土模型”，而是可以被编码、压缩、保存和迁移的状态。Chunk 既是空间划分，也是存储、生成、加载、网络发送和客户端渲染反复使用的工作单位，但这些职责并不意味着“Chunk 已加载”只有一种状态。

时间也不是简单地让所有东西每秒更新二十次。Server Tick 提供了整体节奏，真正的变化却由不同调度机制发生：有些对象每 Tick 更新，有些等待 Scheduled Tick，有些依赖 Random Tick，有些只在邻居发生变化时被唤起。实体移动、AI、红石、光照和流体各自拥有不同的规则与成本。

客户端又看到另一幅图景。服务器里的方块状态不能直接变成屏幕上的世界，它们还要经过 Chunk Mesh、材质、透明排序、粒子、声音和动画。多人环境下，这些表现还必须面对延迟、预测、服务器确认和状态修正。与此同时，近乎无限的世界不可能全部留在内存里，因此运行时始终在决定：哪些区域需要生成，哪些需要读取，哪些应该发送，哪些必须参与模拟，又有哪些可以保存后卸载。

这些系统最终拼成了玩家所感知的“一个世界”，但理解它们的第一步，恰恰是不要急着把它们统一成一种机制。

2这里不是源码导览

Minecraft 已经演化了十多年。今天看到的类、字段、数据结构和线程边界，有些来自明确设计，有些来自多次重构，还有一些是为了兼容旧世界、旧玩法和社区工具留下来的现实结果。

因此这一卷不会按照源码包、类继承关系或 API 名称组织。源码、Javadoc、协议字段和实现细节会出现，但它们主要是证据：用来确认一个系统究竟负责什么、状态在哪一层拥有、一次更新怎样传播，以及某个边界为什么难以改变。

同样，这一卷也不会假定 Minecraft 背后存在一张整齐的“总引擎架构图”。它没有一个统一的 Physics Engine 负责所有具有物理感的行为；方块更新、流体、活塞、实体碰撞和载具运动分散在不同系统里。Java Edition 与 Bedrock Edition 也不是同一架构换了两种语言，而是在长期发展中形成了不同实现、不同语义和不同扩展模型的两条产品线。

真正值得长期理解的不是今天某个类叫什么，而是：为什么这里需要这样的边界，这个边界解决了什么问题，又把什么代价留给了后来。

3从世界数据到长期演化

前五部构成这一卷的主线。

第一部 · 世界与数据从最基础的问题开始：玩家眼中的方块、区块和世界，在机器里究竟是什么。这里会依次讨论数据模型、存档与版本迁移、世界生成。一个世界只有先能够被表示、保存和重新构造，后面的运行时问题才有意义。

第二部 · 世界如何运行把已经存在的数据放进时间里。Tick 提供整体节奏，方块更新、光照、流体、实体、物品、库存和红石则展示了 Minecraft 怎样依靠大量局部规则让世界持续变化。这里尤其重要的一点，是区分“看起来都像模拟”的系统实际上怎样以不同方式工作。

第三部 · 客户端、网络与性能开始处理世界与玩家之间的距离。服务器状态怎样变成画面和声音，多人游戏怎样维护权威状态，Chunk 怎样经历加载、发送、模拟、保存与卸载，以及 FPS、TPS、Ping、内存、I/O 和网络为什么是彼此不同的预算，都在这一部汇合。所谓“卡”，从来不是一个单一问题。

第四部 · 扩展与服务器生态把视角从 Mojang 写下的代码转向社区。数据包和资源包开放的是数据与表现层，Java Mod、Mixin 与 Loader 可以进入代码层，Plugin、Paper、Proxy 和大型服务器基础设施又形成另一条服务端扩展路线。这里研究的不只是“可以改多少”，更重要的是扩展面怎样形成、由谁维护、升级时为什么会破裂。

第五部 · 平台、兼容与长期演化最后把这些机制放回真实产品历史中。Java / JVM 为什么为 Minecraft 带来某些可能，也留下某些约束；Bedrock 为什么逐渐成为另一套实现；存档、协议、Mod、服务器和玩家依赖的历史行为又怎样影响重构。一个长期沙盒最难处理的对象，往往不是今天新写的一段代码，而是已经存在多年的世界和围绕它形成的生态。

到这里，卷三的主线就已经完整：世界怎样存在，怎样变化，怎样被看见，怎样只维护当前需要的部分，怎样被社区扩展，又怎样在长期兼容中继续演化。

4扩展的极限

主线之后还有一个可选专题：扩展的极限。

这里不再按 Minecraft 原版系统继续补知识点，而是反过来挑选少数系统级 Mod，看看前面建立起来的边界究竟能被推到什么程度。

Create 在静态方块世界之上建立机械网络和可运动的 Contraption；Valkyrien Skies 让由体素组成的结构拥有自己的坐标空间和物理状态；Voxy 则进一步分离“能够看见的世界”和“需要完整加载、网格化与模拟的世界”。它们有趣的地方不只是功能强，而是都触碰了原版实现中的某个默认前提。

这些案例不会证明“Mod 一定比原版先进”，也不会变成推荐榜。它们更像三个工程实验：当兼容范围更小、目标更集中、社区愿意承担额外复杂度时，一个已经存在十多年的游戏还能被改到什么程度？

读这一卷时，不需要记住所有类名、Packet 或版本常数。对爱好者来说，理解玩家熟悉的现象背后为什么需要这些系统就已经足够；对开发者来说，更值得带走的是每个系统面对的约束、它选择的边界，以及这些边界在规模、兼容和扩展压力下会发生什么。