2、ERC-721标准深度解析：核心接口、权限管理与实战经验

好，咱们进入第二章节。这一章我打算把ERC-721这个NFT的基石彻底讲透。说实话，很多新手写NFT合约，就是照着OpenZeppelin的模板改一改，但出了问题就抓瞎。我个人习惯是，先搞懂标准本身，再去碰那些封装好的库。这样你踩坑的时候，才知道坑在哪。

2.1 ERC-721核心接口：到底规定了什么？

ERC-721，说白了就是一套“数字物品”的通用协议。它规定了：你怎么证明这个物品是你的？你怎么把它送给别人？别人怎么确认你授权过他？

核心接口就三个函数，我带你过一遍：

// 核心接口 IERC721
function balanceOf(address owner) external view returns (uint256 balance);
function ownerOf(uint256 tokenId) external view returns (address owner);
function transferFrom(address from, address to, uint256 tokenId) external;
function safeTransferFrom(address from, address to, uint256 tokenId) external;
function safeTransferFrom(address from, address to, uint256 tokenId, bytes calldata data) external;
function approve(address to, uint256 tokenId) external;
function setApprovalForAll(address operator, bool _approved) external;
function getApproved(uint256 tokenId) external view returns (address operator);
function isApprovedForAll(address owner, address operator) external view returns (bool);

嗯，这里要注意一个细节：ownerOf 和 balanceOf 是查询用的，不消耗gas。但 transferFrom 和 approve 系列是写操作，要花钱的。

我在项目中遇到过一个问题：有人直接用 transferFrom 从A转给B，结果A根本没授权他。交易直接revert。为什么？因为 transferFrom 要求调用者必须是“被授权的人”或者“owner本人”。

2.2 IERC721与IERC721Metadata：接口的层次感

你可能会问：为什么要有 IERC721 和 IERC721Metadata 两个接口？

我个人理解是：这是Solidity接口设计的一种“分层”思想。IERC721 管的是“所有权和转移”，是最小功能集。而 IERC721Metadata 管的是“这个NFT叫什么？长什么样？有什么描述？”

// IERC721Metadata 接口
function name() external view returns (string memory);
function symbol() external view returns (string memory);
function tokenURI(uint256 tokenId) external view returns (string memory);

说白了，tokenURI 就是NFT的“身份证”。它返回一个JSON的URL，里面包含了图片、属性、描述等信息。我记得有一次，一个项目方的 tokenURI 返回的是IPFS链接，但IPFS网关挂了，导致所有NFT在Opensea上显示不出来。嗯，这就是典型的“链上没问题，链下出问题”。

2.3 OpenZeppelin合约库：为什么大家都在用？

OpenZeppelin 的合约库，说白了就是“经过审计的、社区验证过的”标准实现。你想想看，如果每个项目都自己手写ERC-721，那得踩多少坑？

它的核心实现是 ERC721.sol，你只需要继承它，然后实现自己的业务逻辑就行。比如：

// 使用OpenZeppelin的ERC721
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract MyNFT is ERC721 {
    constructor() ERC721("MyNFT", "MNFT") {
        // 你的初始化逻辑
    }
    
    function mint(address to, uint256 tokenId) public {
        _mint(to, tokenId);
    }
}

这里有个关键点：_mint 是内部函数，OpenZeppelin帮你实现了所有安全检查。比如：不能mint给零地址、不能重复mint同一个tokenId。这些细节，如果你自己写，很容易漏掉。

2.4 Ownable与AccessControl：权限管理的两种姿势

权限管理，说白了就是“谁有权做什么”。在NFT合约里，最常见的需求是：只有合约部署者才能mint、才能设置URI、才能暂停交易。

2.4.1 Ownable：简单粗暴

Ownable 是OpenZeppelin提供的最简单的权限模型。它只有一个owner，所有敏感操作都加一个 onlyOwner 修饰符就行。

import "@openzeppelin/contracts/access/Ownable.sol";

contract MyNFT is ERC721, Ownable {
    function mint(address to, uint256 tokenId) public onlyOwner {
        _mint(to, tokenId);
    }
}

嗯，这个模式适合小项目。但如果你需要多个管理员（比如一个负责mint，一个负责设置URI），Ownable就不够用了。

2.4.2 AccessControl：更灵活的RBAC

AccessControl 实现了基于角色的访问控制（RBAC）。你可以定义不同的角色，比如 MINTER_ROLE、URI_SETTER_ROLE，然后给不同地址分配不同角色。

import "@openzeppelin/contracts/access/AccessControl.sol";

contract MyNFT is ERC721, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant URI_SETTER_ROLE = keccak256("URI_SETTER_ROLE");
    
    constructor() ERC721("MyNFT", "MNFT") {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(MINTER_ROLE, msg.sender);
    }
    
    function mint(address to, uint256 tokenId) public onlyRole(MINTER_ROLE) {
        _mint(to, tokenId);
    }
}

我个人习惯用 AccessControl，因为它更灵活。比如，你可以把 MINTER_ROLE 给一个多签钱包，把 URI_SETTER_ROLE 给运营团队。这样即使运营的私钥泄露，黑客也不能mint新NFT。

2.5 总结：这一章你学到了什么？

好，我们来捋一下：

• ERC-721核心接口：ownerOf、transferFrom、approve 三件套
• Metadata接口：tokenURI 是NFT的“身份证”，要保证唯一性和可用性
• OpenZeppelin库：别自己造轮子，用经过审计的实现
• 权限管理：Ownable适合小项目，AccessControl适合大项目

下一章，我会带你手写一个完整的NFT合约，把今天讲的东西串起来。到时候你会看到，这些接口和权限是怎么在实际代码里配合工作的。

嗯，今天就到这。有什么问题，欢迎在评论区留言。我是你们的区块链架构师，咱们下章见。