ERC-721标准详解：接口规范、核心函数与元数据结构

聊到NFT，绕不开的就是ERC-721。这个标准定义了NFT的基本行为——说白了，就是让每个代币都独一无二，不可互换。我最早接触它的时候，觉得不就是多了一个tokenId嘛，后来踩了坑才发现，事情没那么简单。

ERC-721接口规范

ERC-721的核心接口定义在IERC721.sol里。它规定了所有NFT合约必须实现的功能。嗯，这里要注意，接口和实现是两回事——接口只告诉你「要做什么」，不告诉你「怎么做」。

核心接口包括：

  • balanceOf(address owner) — 查询某个地址拥有多少NFT
  • ownerOf(uint256 tokenId) — 查询某个tokenId的持有者
  • safeTransferFrom(address from, address to, uint256 tokenId) — 安全转账
  • transferFrom(address from, address to, uint256 tokenId) — 普通转账
  • approve(address to, uint256 tokenId) — 授权某个地址操作某个NFT
  • getApproved(uint256 tokenId) — 查询某个NFT被授权给了谁
  • setApprovalForAll(address operator, bool approved) — 批量授权
  • isApprovedForAll(address owner, address operator) — 查询批量授权状态

我个人习惯把safeTransferFrom和transferFrom区分清楚。前者会检查接收方是不是合约，如果是合约，还得实现onERC721Received接口，否则转账会回滚。后者不管这些，直接转。我在项目中遇到过有人用transferFrom转到合约地址，结果NFT永久锁死的情况——嗯，那叫一个惨。

核心函数解析

咱们挑几个关键函数深入看看。

1. balanceOf

function balanceOf(address owner) public view virtual override returns (uint256) {
    require(owner != address(0), "ERC721: balance query for the zero address");
    return _balances[owner];
}

这个函数很简单，就是查一下某个地址持有多少个NFT。但注意，它不接受零地址查询——你想想看，零地址怎么可能持有NFT呢？

2. ownerOf

function ownerOf(uint256 tokenId) public view virtual override returns (address) {
    address owner = _owners[tokenId];
    require(owner != address(0), "ERC721: owner query for nonexistent token");
    return owner;
}

这里有个细节：_owners是一个映射，key是tokenId，value是持有者地址。如果tokenId不存在，返回的是零地址，然后被require拦住。我曾经在调试时忘了检查tokenId是否存在，直接调ownerOf，结果返回零地址，后续逻辑全崩了。

3. safeTransferFrom

function safeTransferFrom(
    address from,
    address to,
    uint256 tokenId,
    bytes memory _data
) public virtual override {
    require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner nor approved");
    _safeTransfer(from, to, tokenId, _data);
}

这个函数做了两件事：先检查调用者是否有权限（是持有者或被授权），然后执行安全转账。安全转账内部会调用_checkOnERC721Received，确保接收方能正确处理NFT。

避坑指南：我曾经在写市场合约时，直接用transferFrom把NFT转给用户，结果用户是个合约地址，没有实现onERC721Received，NFT就卡在合约里了。后来我全部改用safeTransferFrom，再也没出过这种问题。

元数据结构

ERC-721标准本身没有规定元数据怎么存，但OpenZeppelin提供了一个扩展——ERC721URIStorage。它用_tokenURIs映射来存储每个tokenId对应的URI。

// 典型的元数据JSON结构
{
    "name": "My NFT #1",
    "description": "这是第一个NFT，纪念我入坑区块链",
    "image": "ipfs://QmX...",
    "attributes": [
        {
            "trait_type": "背景",
            "value": "金色"
        },
        {
            "trait_type": "稀有度",
            "value": "传说"
        }
    ]
}

你想想看，这个URI通常指向一个JSON文件，里面包含了NFT的名称、描述、图片链接和属性。图片一般存在IPFS上，因为链上存图片太贵了。我记得有个项目把图片直接base64编码塞进URI里，gas费高得吓人——嗯，那显然不是个好主意。

元数据最佳实践：

  • 图片和元数据文件都存IPFS，保证去中心化
  • 属性用trait_type和value键值对，方便市场解析
  • URI长度控制在合理范围内，避免gas浪费
  • 考虑使用baseURI + tokenId的方式，节省存储

标准实现示例

下面是一个完整的ERC-721合约实现，基于OpenZeppelin库。我个人习惯用这个模板起步，省去很多重复工作。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyNFT is ERC721, ERC721URIStorage, Ownable {
    uint256 private _nextTokenId;

    constructor() ERC721("MyNFT", "MNFT") Ownable(msg.sender) {}

    function safeMint(address to, string memory uri) public onlyOwner {
        uint256 tokenId = _nextTokenId++;
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

    // 重写必要函数
    function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

注意事项：

  • 记得重写tokenURI和supportsInterface，否则编译器会报错
  • _nextTokenId从0开始还是从1开始？我建议从1开始，因为0在某些场景下会被当作无效值
  • 只有合约拥有者才能调用safeMint，实际项目中可能需要更灵活的权限控制

说到supportsInterface，这个函数用来告诉外部调用者：我这个合约支持哪些接口。ERC-721要求必须支持IERC721和IERC165接口。OpenZeppelin已经帮我们实现了，但如果你自己写，别忘了加上。

好了，这就是ERC-721标准的核心内容。从接口规范到核心函数，从元数据结构到标准实现，每一步都有它的设计考量。我个人觉得，理解这些底层细节，比单纯会用OpenZeppelin库要重要得多——因为只有懂了原理，出了问题才知道怎么修。

← 上一章 📖 返回目录 下一章 →