图片原始来源 · 官方文档局部引用 · 公开页面局部截图；未修改页面内容
ERC20 和 ERC721 统一的是合约对外接口，不是资产权利。 一个合约能按 ERC20 响应 balanceOf、transfer、approve，只说明它暴露了可替代余额的读写入口；能按 ERC721 响应 ownerOf、transferFrom、safeTransferFrom，只说明它维护了唯一 tokenId 的所有权记录与转移路径。接口兼容不会自动带来投票权、分红权、版权许可、底层资产所有权或赎回权。这些权利来自项目自己的合约规则、法律文件和发行安排，需要逐项核对，不能由“符合 ERC20/ERC721”这句话推出。
两种标准各自统一了什么
ERC20 把同质代币抽象为“账户余额 + 授权额度”。EIP-20 规定 totalSupply、balanceOf、transfer、transferFrom、approve、allowance 等方法及 Transfer、Approval 事件；name、symbol、decimals 属于可选方法。它的基本单位是数量：同一合约内，一个地址持有的若干单位与另一地址持有的同样单位在接口层面没有区别，可以按数量拆分、合并和替换。allowance 允许某地址在限额内代扣另一地址的余额。
ERC721 把资产抽象为“合约地址 + 唯一 tokenId 的所有权”。EIP-721 要求实现 balanceOf、ownerOf、transferFrom、safeTransferFrom、approve、setApprovalForAll、getApproved、isApprovedForAll 等接口，并借助 ERC165 的 supportsInterface 做接口识别。每个 tokenId 单独记录所有者，转移针对具体编号，而不是从余额里扣一个数量。EIP-721 也说明，NFT 可以代表数字或实物资产，但标准本身只负责追踪和转移 NFT。
| 维度 | ERC20 | ERC721 |
|---|---|---|
| 记账单位 | 地址余额数量 | 唯一 tokenId |
| 单位之间关系 | 同合约内同单位可互换 | 不同 tokenId 分别追踪 |
| 授权方式 | approve 设置 allowance 额度 |
单枚 approve，或 setApprovalForAll 授权操作者 |
| 转移对象 | 一定数量 | 指定 tokenId |
| 标准能保证的 | 接口可被钱包、交易所等按统一方式调用 | 接口可被钱包、交易平台等按统一方式调用 |
| 标准不能保证的 | 投票、分红、赎回、底层资产权利 | 版权、许可、实物交付、投资收益 |
表中最后一行是理解这个问题的关键：标准是接口约定，不是权利清单。
授权与转移上的两个细节
ERC20 的 approve 把某地址的可用额度设为指定值，再次调用会覆盖原额度。EIP-20 提醒客户端，在同一 spender 的额度变更场景中，先把额度设为 0 再设新值，以缓解旧额度被抢先使用的风险；这是客户端操作建议，不等于标准本身消除了所有额度竞争问题。
ERC721 的授权要分两层看。单枚 approve 只针对某个 tokenId；setApprovalForAll 则授权一个操作者管理该持有者名下的 NFT。转移某个 tokenId 时，该枚 NFT 的单枚授权会被清除，但持有者此前给操作者的全局授权不会因此自动撤销。把两者都说成“转移后授权一并重置”并不准确。
另外，tokenURI 属于 ERC721 的可选 metadata 扩展，不是所有实现都提供；即使方法名存在，也不证明其行为一定符合标准，仍要核对实际返回值、事件和状态变化。
一个便于自查的例子
假设两个合约都宣称兼容标准。合约 A 是 ERC20，某地址余额为 1000，调用 transfer 转出 300 后余额变为 700；也可先 approve 某地址 200 的额度，让对方在 200 以内通过 transferFrom 代扣。接口层面，这只说明数量记账和授权额度可用。
合约 B 是 ERC721，某地址拥有 tokenId = 42。调用 ownerOf(42) 应返回该地址；转移时必须指定 42，不会把“42 号的一部分”转出去。若项目方声称持有 A 可参与治理，或持有 B 可获得图片商业使用权，这些都不是标准自动赋予的。需要继续查：项目合约里有没有治理、快照或分红逻辑；法律文件如何约定许可范围、期限和转授权；NFT 的元数据指向什么、是否可变、由谁修改。
判定方法：先分三层
第一层看接口。确认 ERC20 是否存在 balanceOf、allowance、transferFrom；ERC721 是否存在 ownerOf、safeTransferFrom，以及 supportsInterface 是否返回对应接口标识。这一层只回答“能否按标准调用”。
第二层看记账语义。ERC20 要看余额和 allowance 是否按数量扣减，额度变更是否按先归零的建议处理；ERC721 要看 tokenId 是否唯一、转移后 ownerOf 是否更新、单枚授权是否随转移清除、全局操作者授权是否仍保留。这一层回答“标准记账是否被正确实现”。
第三层看权利来源。把项目合约中的额外函数、发行文件和链下法律文件分开核对：代币是否可投票，票权按余额还是按快照；收益分配由哪个合约执行，参数是否可改；NFT 的版权许可写在哪份文件，是否随转移而转移；所谓“对应实物”由谁保管、如何验收。冻结、增发、黑名单、转移收费、元数据修改等规则，与标准兼容与否是两件事，必须单独阅读。
把 ERC20/ERC721 当作“调用说明书”，不要当作“权利证书”。 先确认接口和记账，再回到项目合约与法律文件确认权利；两者都成立，才谈得上“持有这个 token 意味着什么”。