一笔交易的“收据”：Receipt 和区块体里的它不是一回事
以太坊上每笔成功打包的交易，除了进入区块的那部分数据，还会生成一份独立的交易回执（Transaction Receipt）。区块里记录的是“你提交了什么”，回执记录的是“执行完之后世界变成了什么样”：这笔交易最终成功还是失败、实际消耗了多少 gas、执行过程中合约发出了哪些事件（Logs）。区块浏览器“代币转账”列表页里的每一行，几乎都是从这些 Logs 里整理出来的。
回执里值得看的四类字段
状态（Status）：一笔交易只有成功和失败两种终态。失败的交易回执同样存在，同样花掉了 gas，只是所有状态改动被回滚，Logs 也不会留下“半截”记录。
Gas 用量：记录限额（gas limit）与实际用量（gas used），是排查 out of gas 和估算成本的第一手数字。
合约地址：如果是部署新合约的交易，这里会给出新合约的地址；普通交易该字段指向接收方或为空。
Logs（事件日志）：本次执行中合约主动发出的结构化记录，每条 Log 由三部分组成——发出日志的合约地址、主题（Topics，最多三个，通常第一位是事件类型的哈希、后面可以跟被索引的地址等关键参数）、数据区（Data，放不便作为索引的长内容，如金额）。主题用来“查”，数据区用来“读”。
代币转账是怎么被“记下来”的
ERC-20 代币的余额是合约账本里的数字，转账本质是合约改数字。合约改完数字后会发一条 Transfer 事件，主题声明事件类型，两个索引主题分别放付款方和收款方地址，数据区放转账数量（注意是带小数位的原始整数）。区块浏览器订阅各代币合约的这些 Transfer 事件，按地址建索引，这就是你在地址页看到“代币转账”标签页的原因。这也是为什么同一笔交易里可能同时出现多条 Transfer——路由兑换会一次发出多条；也解释了为什么有人明明转账失败却似乎“发过币”：失败的执行不会留下事件，任何声称“交易失败但币已发出”的截图多半是伪造或误读，核对方法见区块浏览器交易详情页怎么读？转账成功不成功一看便知。
用 Logs 核对一笔转账是否真实：三步
第一步，别只看有没有“转账记录”，要看记录出自哪个合约地址：地址页“代币转账”列出的那行，点进去核对事件里的合约地址与你预期代币的合约地址一致（合约真假问题见代币真假怎么辨？转账前怎么查合约）。 第二步，核对事件里的付款方、收款方和数值。Data 区是原始整数，除以代币的小数位数才是可读数量，小数位对不上就会出现“看起来多一截或少一截”的误读，核对方法见代币小数位怎么核对？钱包显示余额差了几个数量级的真相。 第三步，把 Logs 与代币持有者账本对得上：真正改变余额的是合约账本，事件只是账本变动的声明，两者应始终一致；不一致时以合约状态为准（可用只读合约查询复核，见Read Contract 怎么用？不连钱包直接查链上数据）。
边界：Logs 不能证明什么
Logs 是合约“自己声明”的记录，恶意合约可以发出误导性的事件；Logs 也不是账本本身，它只是索引材料。因此重要核对要走“合约状态 + 事件日志”双源：状态确认余额，事件确认过程。想读懂交易中调用的方法本身，可延伸阅读交易的 Input Data 怎么读？方法选择器与参数解码。另一个实用视角：用区块浏览器的 API 或 eth_getTransactionReceipt 接口可以批量取回执，做对账和自动化监控时，Logs 里的 topics 正好可以当作过滤条件（例如按事件类型和收付款地址筛出某类转账），这比逐条肉眼比对高效得多，接口用法见区块浏览器 API 怎么用？密钥申请、速率限制与字段口径。
本文仅解释链上数据结构，不构成投资建议；核对具体交易时请以链上可复核字段为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。