如何最简查询ERC-721合约指定NFT Token ID是否已铸造

所有严格遵循ERC-721标准的合约，都强制实现了ownerOf(uint256 tokenId)接口，按照EIP-721规范要求：

• 传入的Token ID已铸造时，无论后续发生过多少次转账、交易，该方法都会返回当前持有人地址，不会revert
• 传入的Token ID未铸造时，该方法必须直接抛出异常回滚交易

这个特性完全匹配不关心铸造后流转、只判断是否完成铸造的需求，是通用度最高、实现最简单的判断依据，不需要依赖合约的非标准内部实现，也不需要遍历历史交易事件。

链上Solidity实现 #

直接用try-catch包裹标准接口调用即可，不需要额外引入其他复杂依赖：

import "@openzeppelin/contracts/token/ERC721/IERC721.sol";

function isTokenMinted(address nftAddr, uint256 targetTokenId) external view returns (bool) {
    try IERC721(nftAddr).ownerOf(targetTokenId) returns (address) {
        return true;
    } catch {
        return false;
    }
}

链下脚本/前端实现 #

用任意Web3库发起view静态调用即可，通过捕获返回结果判断状态：

// 以ethers.js为例，提前初始化好RPC provider、挂载了标准ERC721 ABI的合约实例
async function checkMintStatus(targetTokenId) {
  try {
    await nftContract.ownerOf(targetTokenId);
    return true;
  } catch (err) {
    return false;
  }
}

避坑说明 #

• 不要通过totalSupply返回值判断：支持跳号铸造、燃烧机制的NFT集合，总供应量和具体Token ID是否存在没有对应关系
• 不要遍历历史Transfer事件判断：依赖RPC节点的事件存储完整性，查询效率低，容易因为节点同步问题返回错误结果
• 不要直接读取合约内部存储映射：不同团队的ERC721实现存储布局不统一，直接读存储的方案没有通用性，很容易出现兼容问题

内容的提问来源于stack exchange，提问作者mhmd