NFT 转账失败的报错词典：ERC-6093 给常见失败起了标准名字

为什么同一个挂单有人秒成交、有人却被一句“执行失败”打发？失败不可怕，可怕的是失败不解释原因。ERC-6093 的做法是给最常见的失败场景预先起好标准化的错误名，让钱包和区块浏览器能解码出结构化参数而不是显示乱码。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案标注 Final。

为什么老标准里没有错误定义

Solidity 从 0.8.4 起支持自定义错误，比往字节码里塞长篇 revert 字符串更省 Gas、还能携带参数。但 ERC-20、ERC-721、ERC-1155 定稿都早于这个特性，规范里根本没写错误定义。ERC-6093 不修改任何旧标准，只是补一份“社区公认的报错词典”：实现方可以选用，但不选用也合规。它明确自己只定义错误长什么样，不规定什么时候必须抛——是否回退仍由对应代币标准和实现决定。

对着 ERC-721 的七个高频错误

以 NFT 最常见的失败为例，词典里有一组带地址与编号参数的错误。ERC721InsufficientApproval(operator, tokenId) 直指授权缺失：市场作为操作员没拿到这枚代币的转让许可，对应动作是去代币页核对 getApproved 与 isApprovedForAll；ERC721NonexistentToken(tokenId) 说明这个编号根本不存在，常见于复制错了合集或编号；ERC721IncorrectOwner(sender, tokenId, owner) 表示币不在发起方手里，多半是挂单后币已经转手、订单过期变脏；ERC721InvalidReceiver(receiver) 落在接收端，典型场景是把 NFT 转给一个没有实现接收检查的合约地址；ERC721InvalidApprover 与 ERC721InvalidOperator 则把问题定位在签名授权与批量授权的主体上。每个错误都自带现场参数，读错不再靠猜。

排查动线与一个安全提醒

批量转账专属的数组长度错误

ERC-1155 场景还多了一条独享的报错。ERC1155InvalidArrayLength(idsLength, valuesLength) 直译就是“两个数组长度对不上”：safeBatchTransferFrom 要求编号数组与数量数组一一对应，任何拼装脚本少传一位、多传一位都会撞上它。批量操作最恼人的地方在于报错发生在整笔交易层，界面常常只提示“失败”，回解码后就能看到两个长度值，几秒定位问题。与之相邻的是 ERC1155InsufficientBalance(sender, balance, needed, tokenId)，它在同名错误家族里唯一带着 tokenId，用来解释“哪一种编号份额不够”，对半同质化合集的排错尤其直接。把这些错误名背下来没有意义，重点是养成同一个习惯：失败先解码，解码看参数，参数指向哪个字段就去哪个字段页核对——比凭经验乱重试省时间，也少踩重复扣 Gas 的坑。

给面板开发者的解码提示

工程上，解码标准错误的入口是 revert data 的前 4 字节选择器：先算错误签名的哈希前缀，命中已知表就按 ABI 解码参数，未命中再回落到字符串 revert 或泛化提示。OpenZeppelin 系实现自 5.x 起大量改用这套错误，因此同一市场里新旧合约混存是常态，面板最好两套解码器并联。另一个易错点：相同的 4 字节前缀理论上可能撞上其他同名错误定义，关键场景应把参数个数与类型一并校验，而不是只看前缀打标签。把这三层写进解析器，报错体验就从“玄学”变成“字典”。

与浏览器页面配合的小习惯

把报错词典用顺之后，值得固定一个小习惯：每次失败都先复制 revert data 前 8 个字符（0x 加选择器），存进自己的笔记表，同一选择器反复出现就说明是结构性问题而非偶发拥堵，值得升级处理而不是继续重试。

实操顺序建议：失败后先拿交易哈希到浏览器看 revert 数据能否解码成上述标准错误；能解码就按参数直接定位——缺授权去补授权、币不在手先去持仓页确认归属、接收方问题就换一个普通地址；遇到旧合约用 revert 字符串而非标准错误的，回到字符串提示本身排查。ERC-6093 正文还专门警告：界面不应盲目相信任意合约抛出的错误解码——恶意合约可以伪造标准错误名诱导你执行下一步，解码结果只是线索，行动前以模拟交易和合约源码为准。本文为故障排查科普，不构成任何投资建议；标准文本以 ethereum/ERCs 仓库为准（核验时间 2026 年 9 月 9 日）。