代币编号占位符替换到底是谁的功能：ERC-721 标准正文为什么找不到它

场景：同一个合约，两个工具两种结果

有些 ERC-721 合约把 tokenURI 写成带 {id} 的模板，比如 ipfs://xxx/metadata/{id}。有的浏览器照字面直接访问这个地址，结果 404；也有的工具能把编号塞进去正常显示。于是出现一个典型困惑：ERC-721 到底有没有花括号替换这个功能？

先把结论放前面：ERC-721 标准正文没有定义任何花括号替换，定义它的是 ERC-1155 标准，而且规范里针对的是 ERC-1155 的 uri 函数。你在 ERC-721 上看到的替换，是生态工具从 ERC-1155 借来的行为，不是 ERC-721 的协议义务。

两份标准各自怎么写

ERC-721 对元数据的规定很朴素：合约提供 tokenURI 函数，传入编号，返回一个字符串；标准描述的元数据 JSON 里有 name、description、image 等字段。它没有提到 {id}，也没有规定任何占位符语义——编号与元数据的关系由合约自己实现，常见做法是每个编号铸造时登记各自的 URI。

ERC-1155 则明确写着：如果任何 URI 中出现 {id} 字符串，客户端必须把它替换成代币编号的十六进制形式。它的动机很实际：一个合约管理上万种编号，每个编号存一条 URI 太贵，于是允许一条带占位符的模板覆盖全部。

还有一个容易忽略的责任划分：替换发生在客户端。合约返回什么字符串就是什么，是否执行替换、按什么进制替换，都是读它的软件决定的。

那为什么 ERC-721 上也能看到它生效

因为 ERC-1155 流行之后，不少面向多资产的工具把“花括号替换”做成了元数据抓取管线里的通用步骤，遇到 ERC-721 的 tokenURI 也顺手执行。这是跨标准的工程惯性：写法看起来像，就先支持了。对普通读者的含义是：

• 同一个 ERC-721 合约，在支持替换的显示端能出图，在严格按字面访问的端显示为空，不代表资产有问题；
• 反过来，如果项目方把 ERC-1155 的习惯带进 ERC-721 合约，指望“所有客户端都会替换”，那这个假设只对一部分工具成立，展示覆盖率天然是残缺的。

判断某个 ERC-721 合约到底给编号发了什么元数据，最稳的办法是直接调用 tokenURI(编号) 拿到原始字符串，自己决定怎么访问。工具显示只是缓存与推测，合约返回才是第一手事实。

对铸造者和研究者的建议

铸造者角度：如果确实想用模板省成本，优先选 ERC-1155，或者至少保证 ERC-721 合约返回的 URI 在不替换的条件下也能解析（按编号预登记、或用前缀加完整路径拼接）。把跨标准习惯当默认行为，是在给未来的显示问题埋雷。

研究者角度：写脚本抓某合约的元数据时，先对两个不同编号调用 tokenURI 或 uri，比较返回串是否相同。若相同且包含花括号，就按十六进制规则再拼一次并同时记录两种结果，方便判断目标工具走的哪条路径。

顺带澄清几个相近问题

ERC-721 的 baseURI 和花括号是一回事吗？ 不是。baseURI 是元数据 JSON 里描述共享前缀的字段约定；花括号替换是 ERC-1155 定义、由客户端执行的 URI 处理步骤。解决的问题相似，实现层面互不相干。

能不能用接口探测花括号支持？ 不能。协议没有为它分配接口标识，它不属于任何接口声明体系。探测不到不等于合约没这么写，只说明标准没为它设计开关，答案只能回到合约源码与返回文本。

动手验证的十分钟流程

判断某个合约走哪条路，有个十分钟就能做完的流程。第一步，挑两个差异大的编号（比如 1 和 1000），分别调用 tokenURI，把两个返回值并排放：如果返回串完全相同且内含花括号，这是模板写法；如果每次返回都不同，编号与元数据的关系已经由合约登记好了。第二步，对模板写法手动拼两个 URL：一个把编号换成十六进制串，一个直接用十进制，分别访问看哪个有内容。注意 ERC-1155 对十六进制串有严格格式要求：小写、不带 0x 前缀、必要时补零补齐到 64 个十六进制字符——差一个前导零都会 404。第三步，看两家工具的表现：显示正常的工具多半做了替换，空白的多半按字面访问。这套流程同样适用于排查“别人的钱包有图、我的没有”这类问题，结论通常落在工具差异而不是资产差异上。

风险提示：本文为代币标准机制科普，不构成任何投资建议。展示端差异只反映工具实现差异，链上合约状态与原始返回才是第一手依据。