ERC-20代币解决了什么问题
ERC-20是一套面向同质化代币的智能合约接口规范。同质化意味着同一代币中的单位具有等价属性，不像非同质化代币那样分别代表具有不同属性的独立对象。通过统一的函数和事件，钱包、区块链应用及其他合约可以用相对一致的方式读取余额、查询总供应量和执行转账。
常见接口包括名称、符号、小数位数、总供应量、余额查询、转账、授权以及基于授权额度的代扣转账；Transfer和Approval事件则用于记录转账与授权变化。需要注意的是，符合接口并不等于业务逻辑一定安全，供应量规则、权限控制和额外限制仍然取决于具体合约实现。
代币转账到合约后为何可能丢失
ERC-20的一个典型问题是，用户可以通过transfer或transferFrom把代币发送到某个合约地址，但接收合约未必具备识别和处理ERC-20代币的功能。标准转账流程通常不会要求接收方确认，也没有强制性的接收回调，因此代币可能停留在接收地址中，无法按预期取出或使用。
开发时应区分普通转账和向协议存入代币这两种场景。需要存款的协议通常应设计明确的存入流程，例如先通过approve设置额度，再由协议调用transferFrom完成转入。代币合约也可以考虑阻止发送到自身合约地址等明显错误，但过度禁止向合约地址转账可能破坏与依赖该行为的应用兼容性。
接收代币的业务合约应考虑提供受控的误转资产处理机制，并对资产提取权限、事件记录和可提取范围进行严格限制。若业务需要更强的接收确认语义，也应评估其他代币标准是否更适合，而不能假设所有ERC-20实现都自带安全的接收通知。
decimals不是合约中的小数运算
Solidity和以太坊虚拟机中的代币余额通常使用整数表示。decimals主要是展示和换算约定，用于告诉钱包或前端应把内部整数按多少位进行显示，并不会让合约内部直接进行小数计算。比如一个设置为18位的小数代币，用户界面显示的一个代币，对应合约内部的一百万亿亿等更小单位的整数表示。
因此，铸造、转账和供应量计算都必须使用最小单位。前端、脚本和合约之间若对decimals理解不一致，就可能出现数量显示错误、输入精度丢失或授权额度与用户认知不符的问题。开发者应在测试中覆盖整数边界、不同精度配置和前端换算，并避免把用户输入的展示值未经安全校验直接传入合约。
供应量与权限应如何检查
代币开发中的另一个常见问题是供应量规则不清楚。初始供应量可以在部署时铸造给指定地址，也可以由合约在满足条件时继续铸造；无论采用哪种方式，都应明确谁拥有铸造权限、是否存在上限、权限是否可转移，以及权限变更是否会留下可审计的事件记录。
开发者还应区分余额查询、总供应量和实际业务资产之间的关系。ERC-20接口只描述代币账本行为，并不会自动证明代币具有某种储备、兑换或治理权利。任何额外承诺都需要独立的业务机制、权限设计和验证流程支持。
approve与transferFrom有哪些注意点
approve用于允许第三方账户在指定额度内代表持有人转账，transferFrom则执行实际扣款。授权额度是独立于账户余额的状态，开发者必须同时检查余额和allowance，并在转账成功后正确更新额度。前端也应清楚展示授权对象和授权数量，避免用户误把长期或过大的额度理解为单次转账。
涉及授权修改时，还要谨慎处理旧额度尚未使用、额度被重新设置以及并发交易等情况。合约设计应遵循明确的状态更新顺序，使用成熟库实现基础ERC-20逻辑，并针对授权、转账失败、事件参数和权限边界编写测试。
部署前的实用检查清单
部署前至少应确认：代币名称、符号和小数位数是否符合产品需求；初始供应量是否按最小单位计算；铸造、销毁和暂停等扩展功能是否有明确权限；transfer、transferFrom、approve及事件行为是否与预期一致；向代币合约地址或普通合约地址误转时是否有相应防护；合约是否经过针对边界条件和异常路径的测试。
同时要检查与钱包、区块链浏览器及其他协议的兼容性。不能只测试正常账户之间的转账，还应测试零地址处理、余额不足、授权不足、重复调用、极大数值和意外代币进入业务合约等场景。ERC-20提供的是互操作性基础，不是完整的安全方案，最终风险仍取决于具体实现和外围系统。