查 ERC-1155 供应量先问 exists：ERC-5615 补上的两个函数

给 ERC-1155 合约写数据分析脚本的人常卡在一个基础问题上：某个编号的代币一共发行了多少枚？原始标准里竟然没有现成函数能问出这个问题。ERC-5615 就是为补这个洞而生的。

原始标准的缺口

ERC-1155 的账本按“地址到编号再到余额”的映射组织，标准函数提供 balanceOf 与 balanceOfBatch，查的是某人持有多少。至于某个编号全网有多少枚，合约完全可以不暴露，只能靠外部程序遍历全部 TransferSingle 与 TransferBatch 事件，把铸造与销毁逐笔累计。这对合约开发者是重复劳动，对查询方则意味着要么依赖索引器、要么自己扫全历史日志。

两个函数各回答什么

ERC-5615 把社区里早已流行的写法收编为标准，只加两个函数。totalSupply(id) 返回给定编号的代币数量，编号不存在时必须返回零。exists(id) 返回一个布尔：该编号现在存在、曾经存在、或将来可能存在。为什么要多这一个：totalSupply 返回零有两种完全不同的原因——还没人铸造过，或者这个编号根本不会被启用。只看数量分不清这两种情况，exists 就是那把区分钥匙。标准文档特意说明 totalSupply 对不存在的编号不回滚、直接返回零，关心的调用方应该用 exists 判断，两个函数是配套设计。

与 ERC-165 的关系

一个容易踩的实现细节：ERC-5615 明确表示不要求实现 ERC-165 接口发现，官方理由是接口足够简单、加发现机制反而可能与既有实现不兼容；文档说实现可以支持 ERC-165，但调用方不得依赖。也就是说，你不能靠 supportsInterface 判断一个合约有没有这两个函数，探测的正确方法是直接对测试网或只读节点调一次 totalSupply 与 exists，看返回与 gas 表现是否符合预期。

查供应量时还要补哪一步

有了 totalSupply，供应量的铸造侧有数了，但它反映的是合约此刻记的总量。销毁走哪个函数实现、有没有合约把余额转出到黑洞地址之类的特殊处理，各合约逻辑不同。稳妥的分析是两本账对照：一本是合约 totalSupply 给出的官方口径，一本是按事件累计的流通口径，对得上则数据可信，对不上就要读合约源码找差异原因。面板显示与实际可转移量不一致的怪事，多半能在这一步定位。

小结

ERC-5615 解决的是最朴素的需求：问得出总量、分得清有没有。它在 2023 年提出，本质是把社区早已流行的写法标准化，条文设计与 OpenZeppelin 此前的同名扩展实现保持向后兼容。判断一个 ERC-1155 项目数据透明度时，“有没有暴露这两个函数”至今仍是个不错的筛选起点。

对面板口径的实际影响

多数聚合面板对 ERC-1155 集合的“总量”字段来源于事件扫描，而非合约函数：一边是 totalSupply 的合约口径，一边是面板按事件累计的口径，出现偏差时先确认面板是否统计了销毁路径。写数据脚本的读者建议两个口径都留：合约函数回答“此刻账本认定多少”，事件累计回答“历史上流动过多少”，两者差值本身就是有价值的监控信号。 从标准流程的角度看，ERC-5615 属于典型的先有实践后有条文：供应量查询在多个主流合约库里早已实现，标准做的只是冻结函数名与语义，消除各库之间的细微差异。这也是阅读扩展类提案的通用方法：先确认现网主流合约是否已有同名函数，再对照条文判断兼容性，比从头验证实现快得多。

风险提示：本文仅介绍代币标准接口，不构成任何投资建议。代币供应量数据请以链上合约查询为准。