大多数链上的 NFT 是一个合约记全链的账，Flow 反过来：藏品作为资源直接存放在持有人账户里，合约只定义接口的形状。官方仓库 flow-nft 给出的整套规范由三部分拼成——NonFungibleToken 契约接口、MetadataViews 视图库和 ViewResolver 解析契约。钱包和市场端逛 Flow 时读的就是这三样，已在模拟器、测试网和主网的公认地址部署完毕，项目方通常不需要自己重新部署。
第一块是核心接口。实现 NonFungibleToken 的合约要用到两种资源接口：NFT 描述单枚藏品长什么样；Collection 描述一个能装同类型多枚藏品的容器，负责存取与查询里面的 NFT。用户一般把一类藏品装进一个 Collection，存放在合约自己规定的位置，并向外发布 capability。接口还规定了一个 createEmptyCollection(nftType: Type) 函数，要求返回一个空的 Collection——新用户第一次持有某类 NFT 前，得先有这只空盒子。
这套设计的直接后果是”找不到藏品”在 Flow 上有了不一样的解法：藏品不会躺在某个合约的映射表里等你查 ownerOf，它在你自己账户的存储中。钱包扫描账户、按类型打开 Collection、枚举里面的 NFT，持仓清单就是这么拼出来的。转账也不是调一个 safeTransferFrom，而是把 NFT 资源从一个账户搬到另一个账户的资源操作，资源不可复制、不可丢弃的语义在语言层面兜底，这一点与以太坊靠事件索引重建账本的路线是两套心智。
第二块 MetadataViews 解决”元数据怎么被一致地读”。它把 NFT 的信息切成一个个标准化的视图，比如 NFTCollectionDisplay 负责合集的展示信息，NFTCollectionData 负责返回与路径和类型相关的信息，实现方在 resolveViews 里按请求的类型返回对应视图，例如调用自己的 getCollectionDisplay(nftType:)。这套方案的蓝本是社区提案 FLIP-0636，目的是让不同平台面对同一个 NFT 时不用各自猜字段名。
第三块 ViewResolver 是把前两块缝起来的解析层：先问合约”你支持哪些视图”，再按视图类型逐个取值。钱包渲染详情页、市场做列表缩略图，走的是同一套问答，合约没实现的视图就跳过，不会出现把自定义字段猜成标准字段的那种错位。仓库 README 明确说，这套接口供市场、钱包和索引器依赖，用来在任何 Flow NFT 上获得一致的视图。
对写过以太坊 NFT 的人，这三块还意味着迁移时的思维方式要换。EVM 路线上，合约集中记账，tokenURI 返回一个字符串指针，索引器靠扫事件重建每家持仓；Flow 路线上，账本分散在几万个账户的存储里，视图靠现场解析，没有一条”某合约全部持有人”的现成枚举——想统计持有人，只能靠索引器逐账户扫描资源。两种结构没有绝对优劣：分散存储让单账户转账更贴近所有权直觉，但也让全局统计更依赖索引基础设施。读 Flow 藏品数据时，凡是遇到”这个合集有多少持有人”之类的数字，都应意识到它来自某个索引服务的扫描结果，而不是链上一个可以直接单点查询的字段。
写进接口还有一层是版税。flow-nft 的资源导向 NFT 内建元数据视图与版税声明，目的写得很直白：跨应用兼容。对持有人来说，Flow 上的版税同样属于”合约里声明、市场里执行”的范畴，读到声明不等于成交时被执行，核对方式与其他链一致：以链上返回为准，以平台政策为辅。
上手核对一件 Flow 藏品时可以按三步走：第一步在账户里确认持有该类型的 Collection 资源；第二步用 ViewResolver 问支持的视图列表；第三步逐个解析展示与数据视图，把读到的名称、图片引用与前端页面比对。整个流程里没有任何一步需要信任前端页面报给你的字段。规范状态是生产可用，引用其部署地址和版本时以仓库当前文档为准。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。