先明确：代币标准解决什么问题
ERC-20是一种同质化代币标准。所谓同质化，是指同一代币中的单位在类型和功能上相互等价，因此钱包、区块浏览器以及其他应用可以按照统一接口读取余额、总供应量并执行转账。对于希望接入多个区块链应用的代币，遵循通用接口有助于减少集成差异。
ERC-20合约通常包含名称、符号、精度、总供应量、账户余额查询、转账、授权和代扣转账等功能。交易平台是否能够识别某个代币，不能只看名称或简称，还需要确认合约地址、所在网络、接口行为和代币数据是否一致。本文中的“上交易所”仅指代币被某个平台接入或展示，不代表任何具体平台已经支持某个项目。
常见问题一：名称、简称和合约地址容易混淆
同一个名称或简称可能对应多个不同合约，名称本身不能证明代币身份。识别代币时应以部署网络和完整合约地址为依据，并确认平台记录的网络与用户实际转账使用的网络一致。若把不同网络、不同合约或同名代币混在一起，可能导致充值识别失败、余额显示异常或资产进入无法处理的地址。
接入时还应核对合约返回的symbol、name、decimals和totalSupply等信息。钱包或平台通常会根据这些字段展示代币，但展示信息只是界面层数据，不能替代对合约地址和合约逻辑的核验。
常见问题二：decimals不是额外发行数量
ERC-20的decimals用于界面显示精度，合约内部仍以整数记录余额。假设代币精度为18，界面显示的一个代币通常对应合约中的10的18次方个最小单位。钱包、交易平台和程序在展示余额、填写转账数量时，都必须按照该字段换算。
因此，精度设置不一致会造成数量显示错误、转账数量异常或接口校验失败。开发者还需要确认铸造、转账和总供应量的单位保持一致，用户则应关注平台显示的精度和实际合约数据是否匹配。OpenZeppelin的ERC-20实现默认使用18位精度，但合约可以根据设计覆盖这一设置，具体数值不能脱离合约本身推断。
常见问题三：transfer与approve、transferFrom用途不同
transfer用于账户主动把代币发送给另一个地址。approve和transferFrom则构成授权模式：持有人先允许某个地址在额度内代为支出，获授权方再调用transferFrom完成转账。交易平台或其他合约在处理充值、提现或托管流程时，可能依赖授权模式，因此代币合约应正确实现相关函数和事件。
授权额度属于合约状态的一部分，集成方需要读取allowance并正确处理Approval事件。若代币对标准函数进行了非标准修改，例如改变返回值、限制正常转账，或在特定地址上设置特殊规则，通用工具可能无法按预期工作。是否兼容不能只看函数名称，还要结合实际调用结果和事件记录判断。
常见问题四：把代币直接发给合约可能造成损失
ERC-20标准的转账过程不会自动通知接收方合约，也不要求接收方必须具备处理代币的功能。如果用户通过transfer或transferFrom把代币发送到一个不支持ERC-20接收和提取的合约地址，代币可能停留在该地址，后续无法取回。
把代币误转到代币自身的合约地址，是资料中明确提到的典型风险。合约开发者可以对这类地址增加限制或提供误转代币提取机制，但这些措施取决于具体实现，不能假设所有ERC-20合约都具备。使用者在充值前应确认平台提供的充值地址、网络和代币类型，并避免自行向不明合约地址转账。
常见问题五：总供应量和铸造规则需要能被解释
ERC-20只规定记录和操作代币的通用接口，并不统一规定代币必须如何发行。合约可以在部署时铸造初始供应量，也可以根据额外逻辑在后续铸造或销毁。接入方因此需要了解totalSupply的含义、供应量变化方式以及相关权限是否符合项目对外说明。
不能仅凭一个余额或代币简称判断供应量。应结合totalSupply、账户余额、铸造逻辑和销毁逻辑进行核对，并把合约中的最小单位换算成界面显示数量。若平台、钱包和区块浏览器采用不同精度或读取方式，可能出现数值相同但显示不同的情况。
接入前适用的核对思路
对于采用标准ERC-20接口的代币，重点核对四类信息：第一是网络和完整合约地址；第二是name、symbol、decimals、totalSupply等基础数据；第三是balanceOf、transfer、approve、transferFrom和allowance等函数是否按预期工作；第四是Transfer和Approval事件是否能够被正常记录。
这些检查只能说明通用接口和数据的一致性，不能证明某个项目的商业价值、运营能力或资产安全。具体平台还可能有自己的接入要求，必须以该平台公开的技术规则为准。若合约使用自定义转账限制、黑名单、暂停功能或特殊税费逻辑，则应单独确认这些行为是否会影响充值、提现和余额核算。