同一个编号，可以出现在不同系列
阅读区块链NFT资料时，先把“是哪一枚”与“看起来是什么”分开。ERC-721为每枚代币使用TokenID，这个编号在相应合约范围内标识资产；在同一条以太坊链上，合约地址与TokenID共同完成定位，不能只保存一个编号。
假设系列甲和系列乙都发行了编号7，两个合约地址不同，它们就是两枚不同代币，哪怕展示同一张图片。若还涉及另一条网络，则必须额外写清网络。系列名称相似、页面样式相同，都不能替代这些底层定位信息。
编号不是排名，也不必连续
有的合约从0或1顺序编号，但ERC-721不要求所有TokenID遵循这种模式。标准要求调用方不要猜测编号规律。因此，看到编号100，不应直接得出该系列已经发行100枚、它是第100次铸造，或者前99个编号都有效。
这也解释了为什么不能只把一个数字不断加一来推断完整列表。代币可能被销毁，枚举功能又属于可选扩展。要整理系列数据，应先了解合约实际提供的查询方式，而不是把网页编号当作自动连续的数据库行号。
查数量和查这一枚的归属，是两个问题
在符合标准的合约里，balanceOf查询某个地址持有的NFT数量；ownerOf则针对一个有效TokenID返回其当前归属地址。一个地址持有两枚，只说明数量为2，并没有告诉读者具体是哪两个编号。无效代币的ownerOf查询会报错，不能把报错随意填成某个持有人。
例如，地址甲持有7与9，地址乙持有12与15，两者数量相同，但持有内容不同。做页面核对时，应先定位单枚代币，再读取对应状态。把一张只显示“2个藏品”的截图作为某枚NFT归属证据，信息仍然不完整。
历史事件要与当前状态一起阅读
Transfer事件用于描述代币归属变化，包含转出地址、转入地址和TokenID。检查一条历史记录时，仍需保留它所在的网络、合约和交易信息，不能因为另一处也出现编号7，就把两段历史接起来。
还要注意标准中的例外：合约创建期间可以生成并分配NFT而不发出Transfer事件。因此，事件列表适合追踪变动，却不能在所有情况下仅靠一条简单的事件扫描就还原全部初始分配。当前归属、历史事件与初始化方式，是需要相互核对的信息。
图片说明帮助理解，不替代代币身份
ERC-721的元数据扩展可以提供名称、符号和tokenURI等信息，便于应用展示；该扩展不是每个合约必须采用的全部核心功能。图片加载失败与代币无法定位不是同一个问题，图片正常显示也不意味着已核对合约归属。
保存一条便于复查的记录，可以包含网络、合约地址、TokenID、查询时点及当时返回的ownerOf结果。这里讨论的归属仅是合约记录的代币持有关系；图片内容的使用授权或线下权益，应另看相应约定，不能从一个编号中推导出来。