一枚 NFT 多种文件：ERC-5773 之外的多资产路线对比

同一个需求，四种解法

“这个 NFT 除了图，还附带使用手册、3D 模型、音轨、源文件”——需求很朴素，实现却分好几条路。把常见做法摆在一起看，选择逻辑会清晰很多。

路线一：元数据里放数组

不改变标准合约，直接在元数据 JSON 里放多个文件链接。ERC-721 官方元数据 schema 的核心字段只有 name、description、image，加上可选的 attributes 等扩展；市场普遍另行支持 animation_url 这类多媒体附件字段（OpenSea 文档列出的可接受格式包括 GLTF、GLB、WEBM、MP4、MP3 等），再加上项目方自定义的数组字段。优点是零合约成本、铸造商工具链现成；缺点是除少数被市场识别的字段外，数组里的每个链接都没有链上存在性保证，失效、被替换都无从察觉，合约事件里也看不到资产变化。

路线二：ERC-5773 链上多资产

前一篇文章详细讲过的标准方案：资产在合约里登记，带媒体类型和独立元数据地址，持有人对新增资产有接受或拒绝权，查询接口齐全。它把“资产清单”升格为链上事实。代价是复杂：钱包、市场、桥接工具大多不原生理解多资产接口，展示常退回默认资产，合约开发审计成本也高。适合资产多、要长期治理的严肃项目。

路线三：多合约捆绑

每种资产单独一个合约，用某种“母币”代币把它们关联：买的是母币，钱包里同时出现配套 NFT，逻辑靠关联关系或空投映射维系。以太坊上的链游装备类常见此法。灵活性最强——资产可以分别定价、分别流通。但结构对普通用户不透明：转让母币时配套资产跟不跟走，完全看合约实现；漏投、错投、索引延迟都会造成“我买了套装怎么少件”的纠纷。核验要点是查清每件资产的合约地址和绑定逻辑，而不是只看套装页面。

路线四：目录加槽位（ERC-6220 思路）

把“资产”建模成装备系统：Catalog 合约定义一件件可装备的部件，主 NFT 有槽位，部件铸到专门的 ERC-1155 类合约里，再装备进槽位。它本质上不是“携带多文件”，而是“组装多个可替换资产”，适合游戏与可定制身份头像。复杂度和路线三相当，但语义上支持换件、改装和拆解出售。

怎么选

决定因素其实不是优雅与否，而是流通与兼容：以转手为核心场景的资产（收藏类），路线一最省事，因为所有市场都认；资产长期演化、多方共建的（元宇宙地产、跨游戏道具），路线二或四的治理结构值得付出兼容成本；资产各自流通的（组合式收藏），路线三自然。

一个共同提醒：无论哪条路线，“多文件”都不等于“多权利”。手册、源文件、模型的版权与使用权要靠项目条款说明，文件在链上存在只能证明被登记过，登记本身不分配复制、改编或商用许可。另一个共同提醒是索引时差：所有路线都依赖索引器把资产变化翻译成可读展示，链上刚发生的事件在商品页上可能滞后数分钟到数小时，交易临界时刻（结算、快照、装备换件）请以合约调用结果为准，而不是刷新后的页面。最后一条留给长期持有者：资产结构越复杂，迁移成本越高——十年后想把一件“母币加四件子资产加目录装备”的组合整体搬到新协议，需要每层都还在运转，选结构时给“将来搬家”留出接口，是容易被忽略的尽调项。

风险提示：复杂资产结构潜藏合约与索引缺陷，购买组合式 NFT 前逐项核验各子资产，本文不构成任何投资建议。