收据里的日志也能查账：topics 和 data 怎么反查一笔转账

区块浏览器上那行”状态: 成功”并不是链给出的判词，而是一份交易收据（receipt）的摘要。收据里除了成功标志、实际用掉的 gas，还有一组事件日志——对不显示可读界面的合约交互，日志是唯一可靠的对账入口。学会读 topics 和 data，你就能绕开任何第三方界面，直接从链上把一笔操作反查出来。

收据的三样东西

每笔执行完的交易都有一份收据：status（成功为 1，回滚为 0）、gasUsed 与 effectiveGasPrice（两者相乘是本次实际链上支出，反算方法见代币转账筛选三步法：地址方向、区块区间与排序怎么组合成查询条件）、以及 logs 数组。日志数组由被这次调用触发的所有事件按执行顺序排列，一条事件被拆成两块存储：topics 数组最多四个槽，第一个槽固定是事件签名的 Keccak-256 哈希，后面三个槽是被标记为 indexed 的参数（通常是地址、哈希类参数）；data 装其余的非索引参数，按 32 字节一个槽对齐。Etherscan 的”Decoded”视图就是拿合约 ABI 做了这层翻译，翻译逻辑与交易的 Input Data 怎么读？方法选择器与参数解码里 calldata 解码同源。

ERC-20 转账：一条日志拆给你看

ERC-20 的 Transfer 事件有三个索引参数位中的前两个：签名哈希 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef（即 Transfer(address,address,uint256) 的 Keccak-256 值，本地计算核验）标识这是 Transfer，topic1 是 from 地址右对齐 32 字节，topic2 是 to 地址，data 里是金额。金额按代币 decimals 还原的规则见代币小数位怎么核对？钱包显示余额差了几个数量级的真相。反查场景举例：对方说”已经转了你没收到”，拿到交易哈希，如果收据 status 是 1 但 logs 里没有指向你地址的 Transfer topic，那这笔钱根本没进你的地址——钱去哪了，看 Transfer topic1/topic2 里实际写了谁。approve 授权则对应 Approval 事件，查法同构，这也是钱包连接过的网站清单怎么清：断开连接和撤销授权是两件事里说”断连不是撤销、要看链上事件”的底层依据。

需要提醒：有些代币在标准事件之外做额外动作（税、黑名单、限额），收据日志可能显示 Transfer 事件而实际到账金额被 data 之外的机制削减——精度与路由类坑见余额明明够，交易却一直失败：代币精度与路由的暗坑，此类代币的对账口径以两次余额差为最终依据，日志只是线索。

用地址反查所有历史操作

浏览器按地址查询本质上就是按 topic 过滤：把目标地址补成 32 字节后放进 topic1 或 topic2 匹配。Etherscan 系 API 的 getLogs 类接口支持按 address、fromBlock、toBlock、topic0–topic3 组合过滤，密钥与限额用法见区块浏览器 API 怎么用？密钥申请、速率限制与字段口径。写脚本对账时注意两个边界：节点端的 eth_getLogs 对区块跨度常有限制，大跨度要分段；同一条 topic 在不同事件签名下可能复用，所以 topic0 必须也参与过滤，否则会把”恰好第一个参数是你的”其他事件混进来。

如果一笔业务牵涉多个合约（比如 DEX _swap + 两次 Transfer + 自定义事件），日志的条数与顺序就是执行顺序；对账脚本里”最后一条 Transfer 的目标与金额”通常就是用户该核对的最终结果，多笔打包场景见批量转账发完之后怎么逐笔核对：一个哈希背后的几十条结果。

三个高频误读

一、logs 为空不等于什么都没发生：纯转账（无事件代币或原生币）就不产生事件日志，要看收据与余额变化。二、状态成功不等于业务成功：很多合约设计里失败被内部吞掉仍然”成功”回滚，线索藏在 data 返回或事件缺失里。三、topics 里出现你的地址不等于操作由你发起——只要事件里带你的地址就会命中，发起者看的是交易本身的 from，两者经常不同（代付、路由、工厂模式都会分离）。

拿收据的几条通道与各自的坑

同一份收据可以经四种通道获取：浏览器网页（自带 ABI 解码，方便但依赖平台）、公共 RPC 的 eth_getTransactionReceipt（返回原始十六进制，需要自己按 topic0 匹配事件签名）、付费节点服务（同 RPC 但配额和延迟更稳）、以及本地全节点（自己归档的日志最可信）。多通道交叉核对的思路与你核对用的区块浏览器可能是假的：交易哈希的多通道交叉核验法一致：金额和转账人这类关键字段，至少两条独立通道一致才算定案。注意两种特殊情况：交易刚广播时收据为 null，说明还没被打包而不是失败；在需要历史区块日志的场合，部分公共节点不支持归档查询，会直接报 “archive node required”，这时换归档节点或浏览器 API。

日志读法练熟以后，你对”链上发生了什么”的判断就不再依赖任何一块界面的善意。这是自助对账从看余额到看证据的转折点。

风险提示：解析脚本与 API 使用注意不要在请求里携带任何私钥类信息；本文示例仅为机制说明，不构成投资建议，具体事件语义以各合约 ABI 为准。