账户先有原生余额字段，不等于代币清单
ethereum.org的Ethereum accounts页把账户定义为“带有ether（ETH）余额、可在以太坊上发送消息的实体”，并区分外部拥有账户（EOA）与合约账户。两种账户都能接收、持有并发送ETH和代币，但页面在“An account examined”中列出的四个字段里，与资产数量直接对应的是balance：该地址拥有的wei数量；wei是ETH的计量单位，1 ETH等于1e+18 wei。
也就是说，协议状态里为地址准备的原生记账槽位，首先记录的是原生资产ETH，而不是任意ERC-20代币的明细表。学习“区块链数字资产基础”时，应先把“地址上有没有ETH”和“某个代币合约里记了多少余额”当成两套问题，避免把钱包界面汇总余额误当成单一账本字段。
代币余额在合约里用balanceOf查询
OpenZeppelin Contracts的ERC-20文档说明：ERC-20合约跟踪同质化代币，任一枚与其他枚等价。示例合约部署后，可用GLDToken.balanceOf(deployerAddress)查询部署者余额，并用transfer把代币转到其他地址后再分别查询双方balanceOf。文档还强调decimals主要用于显示换算，合约内部运算仍基于整数。
因此，同一地址可以同时：在协议账户字段持有ETH（ethereum.org所述balance），又在多个ERC-20合约各自的映射中持有不同代币余额（OpenZeppelin示例中的balanceOf）。这些余额互不等价，也不能用“地址余额”一个词笼统替代；查看某代币是否足够，必须指向具体合约与其balanceOf结果。
基础核对顺序：网络、原生、再代币
把两份文档合在一起，可以得到一条可操作的学习顺序：先确认所看网络与地址类型（EOA或合约），再读该地址的原生ETH/wei余额，最后按代币合约地址分别查询balanceOf，并按该合约decimals理解显示值。ethereum.org还写明私钥控制的是账户活动与相关资金的托管关系，资金本身记在账本上——这进一步提醒：界面“总资产”是多来源汇总，不是链上单一字段。
写作边界：本文只区分原生余额与ERC-20合约余额两套记账，不展开跨链桥、不报价、不给出充值或交易指令；也不把OpenZeppelin示例中的游戏代币GLD解释成任何真实流通资产推荐。