数据包、资源包与数据驱动

本章命题：官方扩展面（数据包加资源包）是一条被精确划定的边界——表征与数据完全开放，行为与引擎完全封闭；这条线不是技术极限（跨过它所需的能力官方都有），而是政治边界：开放的东西进官方兼容伞，封闭的东西留在模组的无承诺区。若数据包在现有引擎版本内被证明能注册出全新的方块行为，本命题就是错的。

1问题

卷二第 8 章从设计角度看过数据包（「温和模组」，以及何时该承认数据驱动到头了）。本章翻到实现层，回答一个更锋利的问题：官方开放给玩家的那部分引擎，边界究竟划在哪里？用什么划的？为什么划在那里？

这三个问题的答案拼在一起，是理解「再开发」这个命题的最后一块：卷一第 4 章讲了模组的历史授权，卷二讲了可误用系统的哲学，本章讲的是官方亲手建造的那条正式通道——它通到哪里、刻意不通到哪里、以及「刻意」二字的账目。

2为什么有了数据包还是要写 Java

从架构事实说起。数据包能做的事，全部通过**注册表（registry）**发生：引擎启动时先摆好一排「插槽」——战利品表插槽、配方插槽、进度插槽、函数插槽、维度插槽、世界生成插槽——每个插槽规定了数据的长相，数据包往插槽里提交内容，引擎按统一流程加载。

插槽机制的言外之意是：**数据包能做的事，以插槽的存在为限。**你可以提交一万种新配方（配方插槽欢迎你），但你造不出「第 10001 种交互方式」——因为「交互方式」不是插槽，是引擎内部的行为代码，而注册表不对数据包开放「注册新类型」的权限。新增一种方块的行为逻辑、一种实体 AI、一种界面——这些都需要在引擎的类型系统里登记新户口，而登记权牢牢留在 Java 侧。

所以「有了数据包为什么还要写 Java」的实现层答案是：**数据包是向既有的插槽提交内容，Java 是给引擎添加新的插槽。**前者是填表，后者是立法。卷二第 8 章那四条「该写系统了」的判定信号（动词、界面、状态、规模），在实现层对应的就是同一个事实：你的需求超出了插槽的表单格式。

3命名空间世界：门牌号系统

1.13 的扁平化（第 7 章讲过它的迁移成本）在架构上留下了一件比迁移本身更持久的东西：全局命名空间。扁平化之后，每个内容物都有了全名——minecraft:stone、minecraft:oak_log，而第三方提交的内容物以自己的前缀开头：yourpack:ruby_ore。

这个设计的可敬之处在于它的朴素：命名空间就是一套门牌号系统，一个纯文本约定，解决了所有 UGC 平台最古老的问题——重名。一百个数据包都定义「ruby」，互不踩脚；引用官方内容时永远带官方前缀，覆盖谁、引用谁，一目了然。数据包按优先级叠放、同名条目高层覆盖低层的规则，让「微调原版」成为一行文件的事。

更妙的是这个系统的政治含义：官方把自己的领地也放进了同一套门牌系统——minecraft: 前缀没有任何特权，只是众多命名空间之一。官方内容与社区内容在编址上完全平权。这个细节是「数据驱动是承认」这句话在架构层的落款：社区不再是从官方院子里借地方，而是在同一条街上落户。

门牌系统还配了两样基础设施，让数据包成为所有扩展方式里迭代最快的一种。其一是标签（tag）：引擎把「归组」也做成了数据——「哪些方块算镐子可挖的」「哪些物品算木头」都是可追加的标签清单，数据包把自己的新方块登记进 minecraft:mineable/axe 这类官方标签，社区内容就自动接入了原版的全部规则（工具等级、燃烧判定、掠夺行为）。标签是接入协议：不用改引擎，你的内容物就能挂上官方类别的户口。其二是热重载：一条 /reload 命令，数据包即改即生效，不用重启世界——函数、战利品、配方的调试循环从「几分钟一次」压缩到「几秒一次」。数据包作者的迭代速度因此远超模组作者（后者改一行要重启整个游戏），这个速度差反过来塑造了两个生态的性格：数据包社区更像即兴创作圈，模组社区更像工程圈。

4能做与必须写代码：一张对照表

把扩展面画成表。左栏是数据包的合法领地，右栏是必须写 Java（也就是跨过边界写模组）的领域：

表的左右两栏各有一个形容词值得读出来。左栏的关键词是**「填」：所有条目都是「往既有插槽提交内容」——提交的可以千变万化，插槽是引擎定死的。右栏的关键词是「造」：所有条目都涉及「让引擎长出新器官」——器官不进插槽的表单。一眼扫过去就能看出，分界的判据不是「难不难」（有些数据包项目比小模组还复杂），而是「是否要求引擎承认一种它不认识的东西」**。

表的另一个读法是时间轴：左栏在持续变宽——每几个版本官方就把一个曾经的「必须写 Java」降级为「填表即可」（生物群系、世界生成都是近年才搬进左栏的）。这条缓慢右移的边界线，就是官方对「扩展面」的渐进松绑——松绑的节奏由官方独自掌握，这也正是下一节要说的政治。

5资源与数据：一枚硬币的两面

与数据包并肩的还有资源包（卷三第 9 章讲过它是表征层的官方合同）。两者的分工在架构上是严格按运行位置切的：数据包在服务端跑——战利品、配方、函数这些「世界规则」属于权威侧，随存档走，地图作者把数据包塞进存档目录，玩家什么都不用装；资源包在客户端跑——贴图、音效、模型这些「世界长相」属于呈现侧，每个玩家各自安装（服务器可以推荐，客户端可以选择拒绝）。

这个分工的每个细节都有政治账。数据包随存档走，意味着「规则的设计者」可以完全控制作品环境——冒险地图的世界观不会被玩家篡改（第 8 章的地图作者诉求）；资源包归客户端自愿，意味着「长相」是玩家的私人领地——你可以拒绝任何人的审美，官方不强迫。两侧的强制等级，精确对应了两侧内容对玩法公平的影响：规则影响公平所以要统一，长相不影响公平所以随他去。

Bedrock 版把这套双包体系合成了「附加包」一件事，并接上了 Marketplace 的审核发行（第 15 章展开）——同一组需求，两条产品线给出了两种制度答案，又一次。

6政治含义：边界为什么划在这里

现在可以正面回答「边界用什么划的」了：用兼容承诺划的。

回顾整个再开发体系的授权结构（卷一第 4 章、第 11 章）：官方对模组生态的立场是「允许但不承诺」——不承诺 API 稳定，所以模组每次大版本都要自谋生路。而数据包内部完全是另一种气候：官方承诺数据格式向后兼容（老数据包在新版本大体活着）、承诺插槽语义稳定、承诺加载流程可预期。数据包的世界里有合同，模组的世界里没有。

边界就这样划清了：官方把「愿意为之背书的那部分表达自由」圈进了数据与表征；把「不愿背书的那部分」（行为、引擎、渲染）留给无承诺区。这条线不是能力线——官方完全有能力做一个开放的模组 API（社区呼吁了十几年），不做是因为 API 是债务（第 10 章讲过「接口是承诺」）：一旦承诺，引擎重构就被兼容条款锁住，那正是 Mojang 最舍不得付的代价。数据包给了「平台」的名声，躲开了「接口」的债务——卷二第 8 章这句判词，在实现层找到了它的完整账本。

也该给这份合同补上它的灰色小字。数据包的兼容承诺并非铁板：标着「实验性」的插槽（世界生成的自定义部分长期在此）随时可能变形，官方明确不保证实验区的稳定；版本更迭时，数据包格式号也在悄悄涨，太老的数据包同样要迁移。所以更精确的表述是：伞内也分晴雨区——核心插槽（配方、战利品、函数）是承诺的核心区，边缘插槽（实验性生成）是「有伞但随时收」的前院。前院的存在提醒我们：这条边界不是一次画定的死线，而是一条每年都在两边微调、由官方单方面维护的活线——它的每次移动，都是一次本章标题里那个词的实操：政治。

把全书的相关论断串起来收尾：卷一第 4 章的收编原则（动词进正作）、卷二第 13 章的设计方法（留白与收编）、本章的扩展面——三层其实是同一套治理哲学：**官方始终保持对「系统定义权」的垄断，把「内容与表达」分层出租。**租客可以装修（数据包）、可以换皮（资源包），不能动承重墙（引擎）。这套哲学让官方同时拥有了开放生态的名声与集中架构的自由——至于社区要不要一直租下去，那是卷四第 6 章「谁有权重写」要问的问题。

7这一章留下什么

• 爱好者：你写的每一个数据包都在官方的伞下淋不到雨——伞是真心给你的，伞的边界也是真心画好的。
• 开发者：能抄走的是扩展面的分层合同——数据开放（带兼容承诺）、行为封闭（不带承诺），用承诺的边界而非技术边界划线，平台方就同时保住了开放的名声与架构的自由。抄不走的是划线的资格：这条线之所以立得住，是因为线外还有一个繁荣的无承诺区接住溢出的创作者——没有那片海，画线就成了圈禁。