ERC-5773 多资产 NFT：一张图、一个模型、一份说明书装进同一枚代币

一个 NFT 在不同地方长得不一样

一件数字藏品，在游戏里应该是一组 3D 模型，在交易市场里应该是一张预览图，在电子阅读器里应该是 PDF。传统 ERC-721 的 tokenURI 只能指向一份元数据、配一个图字段，所有地方看到的都是同一份。ERC-5773 试图打破这个限制，它在标准仓库中已标记为 Final（最终），被称为“上下文相关的多资产代币”。

思路很直白：一枚代币可以挂多个资产，每个资产记录自己的媒体类型和独立的元数据地址；应用访问代币时，根据自己的场景挑选合适的资产展示。标准文档把它称作“按上下文输出”：同一枚代币，被市场打开时被端上 PNG，被游戏打开时被端上模型文件。

资产在链上长什么样

规范的资产结构里每个条目主要包含：资产编号、媒体类型字符串（例如 image/svg+xml、model/gltf-binary、application/pdf）和一个资产专属的元数据地址。要点有几个：

• 资产不是孤立存在的，而是相当于“带命名空间的 tokenURI”，同一枚代币的多个资产可以指向完全不同的外部文件。
• 每个活跃资产带一个优先级数值，是数组下标式的非连续编号，数值最小者优先级最高。应用不知道该显示哪个资产时，按优先级取。
• 添加资产走确认流程：发行方调用带 acceptOnTrue 参数的添加函数，或者由持有人后续调用 acceptAsset 接受、rejectAsset 拒绝；还有 rejectAllAssets 做批量拒绝，参数里的 maxRejections 用来防止刚发出的资产被顺手拒掉。相关动作会发出 AssetSet、AssetAddedToTokens、AssetAccepted、AssetRejected、AssetPrioritySet 等事件。
• 查询侧提供 getActiveAssets（已生效资产）、getPendingAssets（待确认资产）、getActiveAssetPriorities（优先级数组）、getAssetMetadata（某个资产的元数据）等函数。

最有辨识度的一条规则：修改资产或优先级需要代币所有者和发行方都同意。持有人不能背着发行方换资产，发行方也不能单方面把持有人的资产换掉——这和“合约方随时能改元数据”的普通 NFT 相比，是一个明显的权力再平衡。

适合什么，不适合什么

适合：跨场景数字资产（游戏装备同时要有图标、模型、音效）、数字孪生（证书文件加实拍图加 3D 扫描）、需要“作品加创作说明”分开存的收藏。

不适合：只有一份图片的头像类合集——用这个标准只是徒增复杂度；需要强一致渲染的场景——不同应用对媒体类型的支持参差不齐，某端识别不了 model/gltf-binary 就会静默回退到默认资产，出现“大家看到的不是同一个东西”。

买家视角的三个问题

1. 你买到的资产列表里到底有几个条目？用 getActiveAssets 能看到当前生效的全部资产，别只信商品页的第一张图。
2. 有没有待确认项？getPendingAssets 非空说明发行方正在尝试加东西，要不要接受是你的权利。
3. 每个资产的外部地址是否持久？多资产意味着多个外链，任意一个失效都会影响对应场景的展示，检查每份元数据的存储方案而不是只看一个总 URI。

标准给了结构，兑现仍然靠发行方的每个外链和每个媒体文件的质量。最后给一个视角：如果你同时维护“作品本体加使用说明加社交卡片”这类素材库，多资产结构真正的维护成本不在合约，而在“每次内容更新都要同步 N 个外链”的日常。上线前把每个资产的存储位置、备份策略、由谁负责续费写进运维文档，比选哪条标准路线更能决定三年后这件作品是否完整。

风险提示：NFT 元数据依赖链下存储与媒体兼容，存在展示失效与技术风险，本文不构成任何投资建议。