一枚 NFT 多份档案：ERC-7160 多元数据与“钉选”机制怎么读

一枚 NFT 在 ERC-721 的 Metadata 扩展里只能有一个 tokenURI。可现实里经常出现“一份档案不够用”的藏品：一串循环播放的动画每张图各有各的档案、同一作品要适配竖屏横屏两个比例、或者项目方想留下元数据的修订记录。ERC-7160 就是给这种情形准备的扩展：一枚代币挂多份元数据 URI，并由持有人从中“钉选”一份作为主档案。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准标注为 Final，2023 年 6 月 9 日创建，依赖 ERC-165 与 ERC-721。

四个函数一次说清

扩展的接口标识是 0x06e1bc5b，通过 ERC-165 的 supportsInterface 可以探测。核心函数只有四个。tokenURIs 一次返回三样东西：当前钉选的索引、这个代币全部 URI 的字符串数组、以及一个布尔值说明到底有没有钉选过——设计者刻意把三样信息合进一次调用，省得查询方分三次请求。pinTokenURI 让调用者把数组里某个索引设为钉选档案，必须发出 TokenUriPinned 事件；unpinTokenURI 取消钉选，必须发出 TokenUriUnpinned 事件；hasPinnedTokenURI 则给不需要读取 URI 本身的链上逻辑一个轻量答案，只回一个布尔。四个函数对不存在的代币都应当直接回滚。

向后兼容靠一条硬规矩

多元数据最容易被问的问题是：老钱包、老市场只认 tokenURI 一个函数，会不会显示错乱？标准的回答是规定 tokenURI 的行为分叉：代币有钉选档案时，tokenURI 必须返回被钉选的那份；没有钉选时，必须返回一个默认档案。这样任何只懂 ERC-721 的工具拿到的仍是单一可用的 URI，而懂这个扩展的市场则可以渲染出画廊或轮播。

往数组里加档案不归它管

一个容易被误读的点：ERC-7160 只规定“怎么读、怎么钉”，不规定“怎么往数组里增删 URI”。增删机制明确要求另行实现，标准文本建议增删时发出 ERC-4906 定义的 MetadataUpdate 事件——因为市场对 ERC-4906 的支持已经很普遍，再发明一个通知事件只会造成重复。对持有人来说，这意味着档案列表的变化权大多留在项目方的管理函数里，能改数组的是合约权限，而把哪份设为展示主档的动作属于持有人（参考实现里钉选与取消钉选都要求 msg.sender 等于 ownerOf，不过权限细节被标准留给各应用自定）。

持有人视角的三条提醒

一次完整的核验动线

把前面的零件串成操作：接到一枚宣称支持多元数据的藏品，第一步在合约页调 supportsInterface，输入接口标识 0x06e1bc5b，看它是否诚实应答；第二步直接调 tokenURIs，观察数组长度、钉选索引与布尔位三者的自洽——数组为空却显示已钉选、或索引越界，都说明实现有毛病；第三步翻 TokenUriPinned 与 TokenUriUnpinned 的历史事件，看钉选被换过几次、每次由谁发起；第四步把数组里每个 URI 逐条打开比对，确认展示图与真实文件同仓同源。四个数字、一份清单、一条时间线，任何一环对不上，宣传里的“多元展示”就要打折。顺带提醒：钉选只影响“对外说哪份档案”，不改变任何一份档案的存储寿命，链下服务器上那份即使被钉成主展示档，停机那天照样会失效。

第一，钉选是链上状态，会被索引器记录在事件日志里，换钱包换市场都跟得走，这比某些“仅前端可见”的展示偏好好得多。第二，多档案意味着多来源：数组里每一份 URI 指向的存储都要单独核验，一份 IPFS 档案配一份中心化服务器档案时，后者失效的年限风险依然存在。第三，看到“支持多元数据”的宣传，先到合约上调一次 supportsInterface 加 0x06e1bc5b，再调 tokenURIs 看数组是否真的非空——接口挂名与真实实现是两回事。标准本身不改变代币的转让逻辑，也不新增任何授权面，风险点集中在“展示的是哪份档案”与“谁能改档案列表”两件事上。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。