用 Rust 从头实现的我的世界客户端：支持 1.7.10 到 1.18.2

用 Rust 从头实现的 Minecraft 客户端：支持 1.7.10 到 1.18.2

Minecraft 的客户端选择并不少。官方启动器、HMCL、PCL、PrismLauncher 和 MultiMC 各有定位，但它们本质上都是启动器，主要负责下载游戏文件、管理运行环境和切换版本，真正执行游戏的仍然是 Mojang 的官方客户端。

如果不使用官方客户端，而是换一种语言重新实现一个 Minecraft 客户端呢？stevenarella 就是这样的尝试。它用 Rust 编写，目标是实现一个支持多个协议版本的 Minecraft 兼容客户端，把协议处理、方块数据、世界加载、渲染和基本交互放进同一个开源项目中。

截至 2026 年 8 月 9 日，GitHub 仓库显示 stevenarella 有 1538 个 Star，最近一次推送时间为 2026 年 8 月 3 日，采用 MIT 与 Apache-2.0 双许可证。项目 README 列出的协议矩阵覆盖 1.7.10 到 1.18.2，共包含 28 个游戏版本或快照条目。项目仓库

为什么有人要重写 Minecraft 客户端

官方客户端的功能已经很完整，但它也有一些限制。

首先，官方客户端是封闭实现。开发者无法直接修改内部渲染逻辑、替换核心数据流程，也不能随意把它移植到 Mojang 没有提供支持的平台。想从底层改造客户端的人，通常只能依赖模组、补丁或外部工具。

其次，不同 Minecraft 版本之间存在明显差异。即使启动器能够管理多个版本，玩家仍然需要准备对应的游戏文件、资源和运行环境。连接老服务器时，版本切换和文件维护始终是额外成本。

渲染也是一个问题。官方客户端有自己的渲染路径，开发者可以通过 OptiFine、Iris 等工具扩展功能，但如果想从根本上更换图形架构，仍然会受到原有引擎的限制。

stevenarella 的目标正是从客户端本身入手。它公开源代码，使用 Rust 重新组织客户端逻辑，并将多个 Minecraft 协议版本放进同一个项目中。这样一来，客户端程序不必随着服务器版本变化而完全更换。

多协议支持是项目主线

stevenarella 最容易被注意到的功能，就是多协议支持。README 的支持表从 1.7.10 开始，一直列到 1.18.2，中间还包括 15w39c、18w50a 和 19w02a 等快照版本。项目 README

这种设计的意义在于，玩家不必为每个协议版本维护一套完全不同的客户端。连接服务器时，程序可以使用对应版本的协议处理逻辑，完成登录、服务器列表、世界数据读取和位置同步等流程。

工程难点也在这里。Minecraft 的网络协议并不是固定不变的。不同版本会调整数据包编号、字段顺序、登录流程和数据结构，区块格式、方块状态、聊天组件以及实体数据也会不断变化。

从 1.7.10 到 1.18.2，Minecraft 经历了多次底层数据变化。世界区块从较早的格式逐步过渡到更复杂的区块分区结构，方块数据和方块状态的表达方式也发生过调整。客户端必须在协议层逐一处理这些差异，不能只靠修改几个版本号解决问题。

项目 README 还明确表示，加入新协议时不会删除旧版本支持。这一点很少见。很多第三方客户端只优先维护最新版本，旧版本往往很快被放弃，而 stevenarella 试图让不同年代的服务器继续使用同一套客户端代码。

它还支持部分 Forge 服务器连接。1.7.10 到 1.12.2 使用 FML 协议，1.13.2 到 1.16.5 使用 FML2。不过，这并不代表 stevenarella 能加载 Forge 客户端模组。它支持的是服务器连接协议，客户端侧的 Forge 模组功能并不包含在内。

Rust 实现带来的安全性

Minecraft 客户端需要同时处理网络 I/O、实时渲染、音频、用户输入、世界数据加载、资源释放和物理碰撞等系统。使用 C 或 C++ 实现时，多个线程和子系统之间共享数据，很容易引入空指针、数据竞争或释放后使用等问题。

Rust 的所有权和借用检查能够在编译阶段拦截一大类内存错误，并帮助限制数据竞争。这对于需要长时间运行、同时处理网络和渲染任务的游戏客户端来说很有价值。

性能方面，Rust 编译后是原生程序，语言抽象本身不需要额外的虚拟机层。不过，Rust 并不会自动保证高帧率。实际表现仍取决于区块更新、资源管理、绘制批次、网络处理和线程调度。换句话说，Rust 给了项目较大的优化空间，但当前性能仍然需要通过实际测试判断。

渲染路线：当前并不是 wgpu

原文将 stevenarella 描述为使用 wgpu，但按照当前仓库的 Cargo.toml，项目依赖的是 glow，桌面平台还使用 glutin，并没有 wgpu。因此，更准确的说法是，stevenarella 当前采用的是 Rust 加 OpenGL 相关库的渲染路线，而不是基于 wgpu 统一承接 Vulkan、Metal 和 DirectX 的图形架构。Cargo.toml

仓库确实包含 wasm-bindgen、web-sys 和 www 目录，README 也提到 Web 支持进展。项目同时列出了 Windows、Ubuntu Linux 和 macOS 的构建方式，说明它确实考虑了跨平台运行。

但这些内容不能直接证明 ARM Linux、树莓派或所有 GPU 后端都已经稳定可用。是否能够运行，还要看具体平台的图形驱动、窗口系统和项目当前代码状态。

目前的完成度

需要实话实说，stevenarella 还不是适合日常使用的成熟客户端。项目 README 的态度也很直接，它主要是出于兴趣进行开发，不应被理解成已经准备好替代官方客户端。

按照项目展示和原文描述，stevenarella 已经能够显示方块、实体和基本世界几何体，移动、交互和聊天也有对应的实现。不过，合成、附魔、容器交互等复杂系统可能仍不完整，部分功能也可能存在 bug。

网络部分是项目最容易验证的内容。README 给出了明确的多版本协议支持表，客户端也具备登录、服务器列表和世界加载流程。原文提到过 Hypixel 连接画面，但一次连接演示并不等于对大型服务器的长期兼容保证。更稳妥的说法是，stevenarella 已经具备连接多个版本服务器的实现基础，具体服务器仍需要逐项测试。

它和其他 Rust Minecraft 项目的关系

近几年，Rust Minecraft 生态逐渐形成了不同方向的项目。

Valence 更偏向 Rust 服务端框架，Feather 和 FerrumC 主要尝试实现 Rust 服务端，Azalea 则更接近机器人框架和相关协议工具。stevenarella 的方向不同，它面向的是人类玩家使用的客户端。

因此，stevenarella 的意义不在于和这些项目争夺同一个位置，而在于它直接面对客户端最复杂的几部分：协议兼容、区块数据、渲染、输入和游戏状态。即使项目目前仍处于实验阶段，这些实现也能为 Rust Minecraft 开发提供参考。

项目社区

stevenarella 采用一种名为 OPEN Open Source 的协作模式。README 写明，做出重要贡献的人可以获得仓库的提交权限，项目更接近开放式协作，而不是由少数维护者完全控制的传统开源项目。README 的贡献说明

项目还保留了 Esper 网络上的 IRC 频道，并使用 GitHub Discussions 作为讨论区。当前仓库在 2026 年 8 月 3 日仍有推送记录，不过近期动向不能简单等同于新功能发布，公开记录中也包含依赖更新等维护工作。

stevenarella 不是启动器，也不是模组或服务端工具。它试图从客户端本身开始，用 Rust 重新实现连接服务器、读取世界数据、处理玩家操作和显示游戏画面所需的主要部分。

这项工作的难度很高。Minecraft 的不同版本之间存在大量协议和数据格式差异，客户端还必须同时处理渲染、输入、资源加载和网络同步。stevenarella 目前距离官方客户端的完成度还有很大差距，但它把这些原本隐藏在闭源引擎里的问题，放进了一个可以阅读、编译和修改的 Rust 项目中。

它最终能否成为真正可用的客户端，还要看后续协议支持、玩法完整度、渲染性能和服务器兼容性。至少在现阶段，stevenarella 更适合作为一个客户端重写实验，以及研究 Minecraft 协议和 Rust 游戏开发的开源案例。

项目地址：github.com/iceiix/stevenarella