ERC-1155 的代币编号占位符模板：一个 URI 字符串怎么服务一万个代币

先给直观含义

ERC-1155 是多资产代币标准：一个合约可以同时管理多种编号的代币，每种编号可以有很多份。它的元数据接口是一个 uri 函数，合约里可以只存一个字符串，例如：

https://token-cdn.example/manifests/{id}.json

标准规定：只要 URI 里出现 {id} 这个占位符，所有遵循标准的客户端在拼出实际地址时，都必须把它替换成代币编号的十六进制形式。也就是说，合约里只需要维护一行模板，一万个编号各自对应哪份 JSON，是客户端在访问时现场算出来的。这里最容易踩的坑是进制：替换用的是十六进制，不是日常写的十进制数字，直接拿十进制编号拼 URL 经常返回 404。

标准里到底怎么写的

ERC-1155 把元数据分成两层。合约层的接口就是 uri，传入代币编号，返回 URI 字符串。标准还给了一个可选的 URI 扩展：如果合约实现了它，supportsInterface 在收到接口标识 0x0e89341c 时必须返回真，客户端由此判断对方声明了这套 URI 语义。URI 要指向符合该标准 JSON 结构的文件，并且遵循 RFC 3986 的通用 URI 语法。当某个编号的 URI 被更新时，合约必须发出 URI 事件，同时带上执行更新的地址，方便索引器回溯是谁在什么时候改的。

JSON 层的字段与 ERC-721 接近：name、description、image 等。标准特别建议 image 指向一张 image/* 类型的资源，并给出显示建议：宽度在 320 到 1080 像素之间，宽高比介于 1.91 比 1 与 4 比 5 之间。另一个常被忽略的细节：{id} 的替换不只发生在 URI 函数返回值里——JSON 文件内部任何字符串值中若出现 {id}，客户端同样必须替换，这让同一份模板 JSON 里的图片链接也能按编号分流。

模板式 URI 省了什么、改变了什么

省的是链上存储：一万个编号不需要一万条链上记录，合约状态里只留一条模板。改变的是更新方式：改这个字符串，等于同时改所有编号的元数据指向。这带来两面性。

• 对合理的维护场景（CDN 迁移、修正描述里的拼写错误），一次更新全体生效，成本极低。
• 对持有人来说，作品指向可以整体漂移。有没有改过是 URI 事件的历史记录能回答的事实；改之前项目承诺过什么，是条款问题，不是标准问题。

合约也可以完全不用模板：uri 对所有编号返回固定值、每个编号预先登记独立 URI、或者 base 前缀加编号拼接，都是常见实现。模板替换只是标准给出的其中一种约定。

怎么核验与排查

1. 在区块浏览器或节点上调用 uri(编号)，拿到原始字符串，确认里面有没有 {id}。有就把编号换成十六进制形式再拼 URL。
2. 调用 supportsInterface(0x0e89341c)，看合约是否声明了 URI 扩展。
3. 查该合约的 URI 事件历史：出现过多条，说明元数据指向被改过，时间、执行地址都在链上。
4. 取回 JSON 后检查 image 等字段是否也带着 {id}，避免“合约层替换了、JSON 里还留占位符”的半替换状态。

钱包显示不出某个编号的图片时，模板替换差异是常见嫌疑：有的工具按十六进制处理、有的偷懒用十进制，同一合约在不同平台一边出图一边空白，未必是资产本身的问题。

常见误区

误区一：一个 URI 字符串说明这些代币共享同一份元数据。 不一定。共享的只是寻址模板，实际 JSON 可以每编号一份。要确认，比较两个编号拼出的 URL 是否指向相同内容。

误区二：{id} 由合约替换。 合约返回的就是带占位符的原始串，替换发生在客户端。这正解释了为什么不同客户端表现不一致。

误区三：模板 URI 等于元数据可随意篡改。 模板给了整体改指向的技术可能；改没改是链上事实，会不会滥用是项目信任问题，两者要分开评估。

风险提示：本文讲解代币标准的元数据机制，不构成任何投资建议。不同工具对同一合约元数据的解析进度可能不同，权属与内容以链上合约状态为准。