NFT 的链上库存怎么数：totalSupply、铸造量与销毁量的三本账

同一句“已铸造 8000 枚”，可能对应三种算法

“这个合集一共多少枚”听起来只有一个答案，实际上链上至少存在三本账。

第一本：合约计数器。ERC-721 的 totalSupply() 按规范返回“当前存在的代币总数”，实现里通常每铸造加一、每销毁减一。注意，这是约定俗成的最常用口径——它统计的是“此刻还在的”。第二本：事件账。所有 Transfer 事件里，从零地址发出的记账为铸造、发往零地址的记账为销毁，两者相减是独立于合约的校验路。第三本：编号账。ERC-721A 类实现用 _nextTokenId 做批量铸造的连续编号，它的 totalSupply() 语义是“历史上铸造过的总量”，哪怕其中一部分已被销毁，这个数字也不回落。三份数据对不上时，先确认各自属于哪本账。

这正是用户在两个面板看到不同“供应”的常见原因：一个数的是现存量，一个数的是累计铸造量。都不算错，但用同一个词。

怎么手工核对一份供应量

步骤一，调用合约 totalSupply()，记下数值及其接口（普通 ERC-721 与 ERC-721A 的语义区别在上文）。步骤二，在事件日志里统计铸造（from 为零地址）事件数与销毁（to 为零地址）事件数，用“铸造减销毁”对照第一本账。步骤三，若合约提供 burnedTokens()、maxTotalSupply() 之类字段（ERC-5484 类可烧标准提供销毁查询接口），把它们作为第四五道交叉验证。任何一格对不上，意味着实现有自定义逻辑（团队预留、隐藏款、批量销毁不走标准事件），需要读合约确认。

比特币上的“供应”是另一回事

铭文类资产没有合约计数器。BRC-20 的 circulating 数字来自索引器对全链 inscribe 与 transfer 操作的重放统计，不同索引器对格式歧义（同名 tick、命名空间）的处理不同，数字可以有差异；铭文销毁在协议上表现为输出到 OP_RETURN 等不可花费输出，官方 ord 文档把这类被销毁的对象标记为 burned。Runes 则由 etching 参数声明总量与铸造上限，账本语义完全依赖索引器对 Runestone 的解码。结论是通用的：比特币上看供应，必须知道“这是哪个索引器算的、按哪版规则算的”，没有权威函数可以一锤定音。

面板差异的三个良性解释与一个恶性解释

良性一：现存量与累计铸造量的语义差（上文字）。良性二：统计未同步，索引滞后于最新区块，销毁事件还没入账。良性三：预留与空投走非铸造事件路径，短期让事件账与计数器错位。恶性解释：项目方宣称的“已销毁”与链上销毁事件对不上，或者销毁走了自定义函数不发标准事件、只在公告里出现。遇到“回购销毁计划”这类叙事，唯一认真的问法是：销毁交易哈希给我，销毁后 totalSupply() 或索引器 burned 计数怎么变。

三条使用建议

第一，报告供应数字时永远带口径：现存量、历史铸造量、声明上限，三者选谁要说清。第二，稀有度与地板类指标的计算基础依赖供应口径，同一合集的“通缩叙事”可能只是口径切换的视觉结果。第三，对比特币铭文，至少用两个独立索引器对照关键数字，差异本身就是信息。

一个使用习惯

把所有“总量”话题都当成三元问题来回答：现在的、累计的、声明的上限。以太坊上三本账往往各有一个函数或事件可查；比特币铭文上则要把“哪个索引器、哪版规则”当成第四个必答题。养成这个习惯后，任何“全网最低”“即将通缩”的表述都会自动触发追问：按哪本账算？谁算的？口径换过没有？大多数供应争议在追问下会自己消散，剩下的那一小部分，才值得真的去读合约源码。数据素养在 NFT 领域的体现，不是记住几个指标，而是每次听到数字都条件反射地找口径。

风险提示：本文只解释技术机制与操作边界，不构成投资建议，也不推荐任何项目或平台。链上规则可能随版本升级变化，判断以官方规范文本与链上实际代码为准。