物品、库存与合成

本章命题：物品系统的架构史是一部「技术追随社区」的历史——硬编码配方让位于数据驱动，自由格式的 NBT 让位于组件化，每一步都是玩家把物品用出官方想象之后，架构被迫追认。物品是玩家财产的主要载体，所以它的格式变动天然是兼容地狱。若组件化发生在没有模组生态压力的平行世界里（仅为官方自身的整洁），本命题的因果链就是错的。

1问题

先端详一把具体的剑。它的名字叫「无敌神器」，锋利 V，耐久剩下三分之一，作者签名是三年前某个服务器朋友的 ID。在玩家眼里，它是一件有故事的财产（卷二第 5 章讲过「物品是故事的载体」）。在数据眼里，它是什么？

这个问题的答案在十五年里换了三次，而每一次更换，全网的服务器存档、模组、数据包、工具站都要跟着搬一次家。物品系统是这本书「技术债与设计自由同源」命题的最佳标本：它既是玩家接触最频繁的数据（每分每秒都在增删改查），又是格式最敏感的数据（每一条都是玩家的财产），还是社区创作最密集的接口（模组与数据包的重灾区）。三重身份叠加，构成了本章的全部张力。

2物品为什么难迁

先理解迁移难的根源。世界地形变了，玩家骂两句也就接受了（卷三第 3 章讲过新旧地貌的接缝）；但物品变了，玩家会觉得偷了他的东西——那把「无敌神器」要是搬完家变成了普通铁剑，等于三年游戏时间被部分作废。

所以物品迁移的铁律比地形苛刻得多：地形允许「重新解释」，物品只允许「无损搬家」。无损搬家的难点在于物品数据的两个特性。其一，每件物品都可能不同：同一种钻石剑，附魔、耐久、名字、修饰各有千秋——不能像石头方块那样「同类压缩」，必须逐件保真。其二，数据形状由使用者定义：官方给物品开的字段，社区（模组）会往里塞自己的私货——你的迁移器不光要认识官方字段，还得理解千奇百怪的第三方字段。存档兼容的大头（第 2 章的转换器）在物品这里走到了最窄的巷子。

3栈、NBT 与自由停车的年代

物品的基本单位是物品栈（stack）：同种物品叠成一摞，一般上限 64。一个空手可得的泥土块与一把满附魔神剑，在结构上都只是一条「类型 + 数量 + 附加数据」。前两项简单；全部的麻烦住在第三项——附加数据。

附加数据的载体是 NBT（第 2 章讲过这种「自带标签的收纳盒」格式）。物品栈上挂一个 NBT 标签（tag），里面可以装耐久损耗、附魔清单、显示名字、修饰描述——结构上是个随用随放的停车场。这个设计在官方手里是克制的：耐久、附魔、名字，几个固定车位。但停车场不分车位号，谁都能停：模组给自家的魔杖在 tag 里塞能量值，数据包塞任务进度，服务器插件塞归属标记——同一块停车场，每家画的车位线都不一样。

自由停车的代价随生态规模显现。对官方：物品数据不可预测——你不知道一个 tag 里会有什么，坏数据直接把存档读崩，网络同步也只能整个 tag 打包传输（一箱子复杂物品的同步包大得浪费）。对社区：没有模式（schema）——「能量值」到底存在哪个字段、什么类型、负数合法吗，全看作者心情；两个模组碰巧用了同一个字段名，效果互相覆盖的灵异事件屡见不鲜。自由停车的年代，本质上是「用无结构换取了无限灵活」——生态小的时候灵活是蜜糖，生态大了，无结构就是砒霜。

还有一个容易被忽略的事实加剧了混乱：**物品栏被玩家当成了数据库。**任务道具收藏馆、按年代排列的博物馆箱、纪念品墙——玩家往物品上写的不只是附魔，还有剧情与纪念（第 5 章的「故事载体」落到数据层就是：这些故事全住在那个无结构的 tag 里）。物品数据的实际负载因此远超官方的设计想象：它既是装备系统，又是玩家的日记本。格式改革要搬的从来不是「数据」，是日记。

4组件化：从自由停车场到具名车位

2024 年 4 月的 1.20.5，物品系统完成了史上最大的一次重构：NBT 自由标签被「组件（component）」体系取代¹。新规则一句话：物品的一切可定制属性都登记为具名组件——耐久是 max_damage，附魔是 enchantments，名字是 custom_name；每个组件有官方定义的结构、默认值与序列化规则，未使用的组件干脆不出现。

为什么必须发生？把动机列出来，会发现每一条都指向社区生态的规模。

**其一，可预测性是生态的氧气。**数据包作者和模组作者需要「这个字段一定叫这个名字、一定是这个类型」的承诺——自由停车场支持不了一万个商户。具名车位让「组件」成为可文档、可校验、可跨作品协作的接口：这才是官方格式的模组化，比数据包又往系统层走近了一步。

**其二，带宽与同步的账。**旧制下一个物品的 tag 整体传输；新制下组件按需同步——没改过的组件不必上路。对动辄成千物品流动的服务器（第 6 章的网络税），这是实打实的减负。

**其三，健壮性。**具名组件有校验：坏数据在入口被拒绝，而不是潜行进存档，在读档时引爆。第 2 章讲过的「数据转换器」从此有了干净的输入。

组件化是一次教科书级的「追随社区」：模组圈早就总结出了「具名字段优于自由 blob」的教训（Forge 的能力系统、各类物品属性方案都是先声），官方在原版层把这门课补齐。它同时是卷二第 15 章「约束即深度」在数据层的注脚——放弃无结构的自由，换回可持续的生态，和当初收编活塞的逻辑同源。

5配方数据驱动：又一次追随

配方（怎么合成）的架构史是同一个故事的分身。早年配方硬编码在程序里——想改「钻石剑要几颗钻石」，得改代码；社区想调平衡（服务器常改：原版配方太贵或太便宜），只能写模组。数据驱动配方的需求完全是社区实践喂大的：各种模组的「配方自定义」功能做了多年，把「配方该是数据不是代码」这个结论验证得足够充分，官方才在 1.12 前后把配方迁入 JSON、随 1.13 并入数据包体系——第 8 章讲的「官方追认社区做法」，在配方这里完成得最彻底。

数据驱动之后发生的连锁反应值得一记：配方从程序里解放出来后，立刻成了数据包作者最常用的入口（改个掉落、加个合成是所有数据包的Hello World），整合包的平衡调整（第 13 章的策展设计）也因此成为可能——**一门手艺的公开化，直接创造了一个作者阶层。**技术追随社区，社区回报以繁荣，这条反馈线在配方这里画得最圆。

6窗口协议：库存界面的权威账本

物品的交互界面（背包、箱子、工作台）在协议层有个古称：窗口（window）。窗口协议是「服务器权威」原则在物品层的落地（卷三导读三句话的又一处展开）：客户端画的库存只是预演——你把钻石拖进合成格，屏幕上立刻就位，但服务器不认；等你点下成品，客户端把「我在哪个窗口的哪个格子做了什么」上报，服务器用自己那本账核对（你真的有这块钻石吗？格子真的空着吗？），核完才把权威结果下发。你看到的流畅，是本地预演与服务器裁决的合谋（卷三第 11 章手感谎言的家族成员）。

这套设计让物品交互在糟糕网络下依然诚实：客户端可以假装，账本只有服务器有。它也顺手解释了两件玩家熟知的事：为什么复制物品的漏洞都在「服务器账本与预演的间隙」里（第 4 章连锁更新的网络亲戚），以及为什么窗口协议自身的一次重编号（1.17 把窗口 ID 从 1 开始重排）能让全网反作弊与容器模组连夜改代码——权威账本的任何页面修订，都是全生态的事。

预演与权威的分工里藏着一套精妙的体感经济。本地预演负责「零延迟」——拖拽、摆放、拿取全部即时反馈，手感跟单机无异；服务器裁决负责「零造假」——再灵巧的客户端也造不出没有存货的钻石。两者的交接发生在你真正「提交」的那个点击上：此前的一切都是彩排，此后才有账。玩家从来不需要知道这套双簿记的存在——最好的权威系统，就是让人感觉不到权威的系统；直到有人试图越过它，才发现每个格子背后都有一双不信任何人的眼睛。

7迁移地狱：只增不减的解释器

现在把「迁移地狱」算总账。物品格式十五年三变（原始 NBT、扁平化 1.13、组件化 1.20.5），每一次变动都给第 2 章讲过的数据转换器（DataFixerUpper）添一层新的改写规则。这层规则有两条铁律：只增不减（十年前的旧档还要能升，旧规则一个不能删）与逐件无损（本章开头的铁律）。于是转换器长成了考古地层——每一层对应一个时代的物品格式，任何一件玩家的老古董，都要被逐层翻译到当代。

这就是「物品是兼容地狱」的完整含义：地狱不在单次迁移的技术难度，而在永远不能销账。地形可以重新解释、生成可以换算法，唯有物品必须件件保真地穿越每一次架构革命——因为它不是数据，它是玩家的时间与感情的容器。组件化已经落地，但没有人敢保证它是最后一次：只要玩家还在往物品上写故事，这个故事的数据载体就得一直搬下去。

8这一章留下什么

• 爱好者：你的「无敌神器」在数据世界里搬过三次家——每一次都完好无损，这背后是一套专门为「玩家的过去」设计的翻译体系。
• 开发者：能抄走的是「追随社区」的技术路线图——先允许野蛮生长（自由 NBT），等生态验证出用法，再把验证过的用法格式化（组件化）；以及「具名清单优于自由字段」这条接口铁律。抄不走的是迁移债务的体量：敢让物品格式革命三次，是因为身后站着一套只增不减的转换器体系和一群 48 小时内出兼容版的模组作者——那是一整套社会的工程能力。

注释

1. Minecraft Wiki，《Data component format》（1.20.5 起物品数据由 NBT 自由标签改为具名组件体系：组件有官方定义的结构与默认值，未设置即不出现），minecraft.wiki，检索于 2026-09-18；见 https://minecraft.wiki/w/Data_component_format ↩