1. 以太坊代币标准概述在以太坊生态系统中ERC20和ERC721是最具代表性的两种代币标准。作为区块链开发者我经常需要根据项目需求选择合适的标准。ERC20诞生于2015年由Fabian Vogelsteller提出它定义了同质化代币的基本接口而ERC721则是在2018年由William Entriken等人标准化专门用于非同质化代币(NFT)。提示选择代币标准时首先要明确你的资产是否需要区分个体差异。如果每个单位完全等价ERC20是更好的选择如果需要唯一标识每个资产则必须使用ERC721。这两种标准都通过智能合约实现本质上是一组预先定义好的函数接口。遵循这些标准开发的代币可以无缝兼容各种钱包、交易所和DApp。在我的开发实践中发现90%以上的代币项目都可以用这两种标准覆盖。2. ERC20与ERC721核心差异解析2.1 代币性质的根本区别ERC20是同质化代币(Fungible Token)标准意味着每个代币完全等同且可互换。就像现实世界中的货币——你钱包里的1个ETH和我钱包里的1个ETH价值完全相同。这种特性使其非常适合用于加密货币(如稳定币USDT、USDC)治理代币(如UNI、AAVE)积分奖励系统而ERC721是非同质化代币(Non-Fungible Token)标准每个代币都有唯一标识(tokenId)不可分割且互不相同。这就像艺术品(每个NFT都是独一无二的)游戏装备(每件装备属性不同)数字身份凭证// ERC20余额存储结构 mapping(address uint256) private _balances; // ERC721所有权记录 mapping(uint256 address) private _owners;2.2 底层数据结构对比ERC20的核心是记录地址与余额的映射关系只需要维护每个地址持有的代币数量。而ERC721需要精确追踪每个tokenId的所有者这带来了存储和查询上的差异余额查询ERC20balanceOf(address)返回具体数量ERC721balanceOf(address)返回该地址拥有的NFT数量所有权查询ERC20不需要单独查询余额0即表示拥有ERC721必须通过ownerOf(tokenId)确认特定NFT归属转账逻辑ERC20指定数量和接收方即可ERC721必须明确要转移的具体tokenId3. 授权机制深度剖析3.1 ERC20的单一授权模式ERC20的授权相对简单主要使用approve(spender, amount)函数。这种授权有以下几个特点额度授权允许被授权方支配指定数量的代币可覆盖重复调用会覆盖之前的授权额度风险点如果授权给恶意合约可能导致资金被盗// 典型授权场景允许Uniswap使用1000个代币 approve(0xUniswapRouter, 1000 * 10^18); // 查询授权额度 allowance(owner, spender);3.2 ERC721的双重授权体系ERC721设计了更复杂的授权机制这是由其非同质化特性决定的单NFT授权approve(to, tokenId)授权特定NFT给某个地址使用getApproved(tokenId)查询授权状态全局授权setApprovalForAll(operator, true)授权所有NFT通过isApprovedForAll(owner, operator)检查重要安全提示全局授权要特别谨慎许多NFT钓鱼攻击就是利用用户过度授权得逞的。在实际开发中我建议默认使用单NFT授权仅在确实需要时(如NFT交易平台)才开启全局授权。4. 合约助手实战指南4.1 OpenZeppelin合约向导使用技巧OpenZeppelin合约向导(https://wizard.openzeppelin.com)是我日常开发中最常用的工具之一。它不仅可以生成标准合约代码还能根据需求添加各种扩展功能。4.1.1 ERC721生成策略生成ERC721合约时需要考虑以下模块组合基础必选模块Mintable添加铸造功能Auto Increment IDs自动递增tokenId按需选择模块Enumerable适合需要遍历NFT的场景(消耗更多gas)URI Storage每个NFT有独立元数据时使用Pausable需要紧急停止交易时添加// 典型ERC721合约生成选项 contract MyNFT is ERC721, ERC721Enumerable, ERC721URIStorage, Ownable { using Counters for Counters.Counter; Counters.Counter private _tokenIdCounter; constructor() ERC721(MyNFT, MNFT) {} function safeMint(address to, string memory uri) public onlyOwner { uint256 tokenId _tokenIdCounter.current(); _tokenIdCounter.increment(); _safeMint(to, tokenId); _setTokenURI(tokenId, uri); } }4.2.2 ERC20生成最佳实践对于ERC20代币常见配置组合包括基础功能Premint初始发行量Mintable保留增发权限高级功能Burnable需要通缩机制时添加Permit支持离线签名授权(节省gas)Snapshots需要记录历史余额时使用// 带增发和销毁功能的ERC20合约 contract MyToken is ERC20, ERC20Burnable, ERC20Mintable, Ownable { constructor() ERC20(MyToken, MTK) { _mint(msg.sender, 1000000 * 10**decimals()); } function mint(address to, uint256 amount) public onlyOwner { _mint(to, amount); } }5. 开发经验与避坑指南5.1 常见安全陷阱重入攻击风险ERC721的safeTransferFrom会回调接收方合约解决方案遵循检查-生效-交互模式授权劫持未及时撤销不必要的授权建议定期检查并清理授权整数溢出ERC20转账前必须检查余额使用SafeMath库或Solidity 0.8版本5.2 Gas优化技巧对于ERC721避免使用Enumerable扩展(除非必须)批量操作减少交易次数对于ERC20实现ERC20Permit支持离线签名使用增量更新代替全量快照5.3 元数据处理建议对于ERC721考虑使用IPFS存储元数据实现可变的tokenURI(如游戏装备升级)对于ERC20可以通过EIP-1046添加代币元数据保持符号( symbol )简洁且唯一在实际项目开发中我通常会先使用合约向导生成基础代码然后根据具体需求进行定制化修改。比如最近开发的一个游戏项目我们就在标准ERC721基础上添加了租赁功能和装备合成逻辑。记住标准只是起点真正创造价值的是在标准之上实现的创新业务逻辑。