链上衣柜：ERC-6220 用 Catalog 把 NFT 装备进槽位

先给直观含义

ERC-6220（Composable NFTs utilizing Equippable Parts，2022 年提出，已定稿）要解决一个很具体的问题：一堆 NFT 怎样组成一个链上可验证的整体。文档给出的旧办法有两种——要么无差别扫描账户里所有兼容 NFT 全算进来（遇到同一槽位该用哪个就可能算错），要么在链下或自定义合约里记一张拼装配表。6220 的做法是立一个规则来源：Catalog（目录）。目录里登记部件与槽位，每个 NFT 从目录里挑部件，哪些 NFT 能装进哪些槽，也由目录说了算。

链上衣柜：ERC-6220 用 Catalog 把 NFT 装备进槽位图 2 — 链上衣柜：ERC-6220 用 Catalog 把 NFT 装备进槽位 · 图 2

部件分两种

目录里的部件分两类。固定（fixed）部件是自带完整元数据的成品组件；槽（slot）部件本身是空的，接受其他 NFT 集合的代币装备进来。目录侧还有 Equippable 接口：声明某个装备组可以进哪个集合的哪个槽位，以及 checkIsEquippable、checkIsEquippableToAll 这类“可装备性”查询。

代币侧的装备接口有五个函数值得记住：equip 参数是父币编号、资产编号、槽部件编号、子币的合约地址与编号——装备记录绑定到父币的某个资产（asset）与某个槽，返回资产编号用于确认写进了哪份资产。unequip 按同样的坐标卸装；isChildEquipped 查询某枚子币当前是否处于装备状态；canTokenBeEquippedWithAssetIntoSlot 在动手之前检查目标代币的资产有没有带对应槽的部件、部件是否允许目标集合；getEquipment 返回父币全部槽位的装备情况。

依赖链要交代清楚

6220 不是一块独立积木：它建立在多资产标准 ERC-5773（声明接口 0x06b4329a）与嵌套标准 ERC-6059（0x42b0e56f）之上，6220 自身的声明接口是 0x28bc9ae4。资产是 5773 的概念，父子持有是 6059 的概念。换句话说，一笔装备动作实际同时踩在三层标准上：5773 管“这件 NFT 有哪些资产版本”，6059 管“谁持有谁”，6220 管“哪个子币装进了哪个槽”。

它能说明什么、不能说明什么

能说明：装备与卸下是链上事件，组合关系可以被任何索引器重建，不再需要项目方私下维护一张搭配表；父币易手时，装着什么一目了然。

不能说明：它没有解决兼容集合的元数据统一——子币的画面、属性仍由各自合约定义，槽里装的东西“是什么”，仍然要回它自己的合约看。它也不提供性能或玩法语义，槽位规则怎么写由目录实现者决定。

实用阅读顺序

面对一件支持 6220 的 NFT，三步摸清它的搭配状态：一是 getEquipment，拿到每个槽的装备记录（子币的合约与编号）；二是对每枚在装子币回到它自己的合约核验归属与元数据；三是查对应 Catalog 里该槽的 Equippable 声明，判断哪些资产有资格换进来——这决定了你未来可替换的选项范围。

常见误区

误区一：以为装备等于把子币烧进父币。标准文档的定义里 equip 只是建立装备关系，子币仍是独立代币、仍可卸回，所有权语义走的是 6059 的嵌套路径。

误区二：把“可装备声明”当成“装备保证”。canTokenBeEquippedWithAssetIntoSlot 只是预检，最终以 equip 执行结果为准。

误区三：以为槽位里的内容会自动出现在所有展示端。跨工具展示需要各自实现，没显示不等于没装备。

目录里还有什么

Catalog 不只是槽位表。标准给目录合约也定了接口：每个部件有 getType 声明它是固定部件还是槽部件，getMetadataURI 返回部件自己的元数据，getPart、getParts 供查询，checkIsEquippable 与 checkIsEquippableToAll 回答“这个部件的装备组允不允许装进某集合的槽位 / 任意集合”。文档举的例子很好懂：一张电影 NFT，片尾字幕这类部件应当是固定的，场景部件则应当可替换，好让基础版、导演剪辑版、纪念版的发行各装各的。对照这份分工看装备系统的信息面：哪些部件可换、可换成什么、部件长什么样，都是目录里的链上数据，展示端与索引器可以直接读，不必问项目方。