以太坊交易回执包含什么？为什么没有函数返回值

查一笔以太坊交易时，区块浏览器常把状态、Gas、日志和合约调用详情放在同一页面。它们虽然围绕同一笔交易，却不是同一类数据。标准 eth_getTransactionReceipt 回执主要回答“这笔交易被放进哪个区块、执行状态如何、消耗了多少 Gas、产生了哪些日志”；它通常不提供 Solidity 函数 ABI 的返回值。理解这条边界，能避免把“交易成功”误读为“我已经拿到了合约函数返回内容”。

回执能告诉你哪些事

Ethereum.org 的 JSON-RPC 文档列出的标准回执字段包括交易所在区块、交易索引、状态、累计 Gas 使用量、这笔交易的 Gas 使用量以及日志等。字段各自有范围：区块相关信息定位交易所在区块；交易索引标出它在该区块中的位置；Gas 字段描述消耗；日志数组承载执行产生的日志。回执中的 status 用于表示交易执行成功或失败。

如果交易尚未被打包，查询可能没有回执。这时不能根据“回执为空”推导交易已经失败或成功，它只说明当前查询没有得到该交易的回执。应保留交易哈希，之后再按同一网络查询，并同时确认请求是否发到了预期节点。

信息	回执中的典型字段	能回答的问题	不能直接回答的问题
所在区块	区块哈希、区块号	交易被记录在哪个区块	Solidity 函数返回了什么
执行状态	`status`	执行成功还是失败	失败的完整内部调用轨迹
Gas	`gasUsed`、累计 Gas 字段	区块/交易相关 Gas 使用量	具体业务函数的返回对象
合约事件	`logs`	执行产生了哪些日志记录	所有内部步骤和完整返回数据

事件日志不是函数返回值

事件日志由合约执行过程产生，并作为回执中的日志数据记录。应用可以依据合约 ABI 解码日志，以读取事件参数；但解码出来的事件仍然是事件，不会因此变成函数调用的 ABI 返回值。二者用途不同：事件常供外部系统观察合约行为，函数返回值则属于一次调用执行的返回数据语境。

这也解释了为什么标准回执字段清单里通常找不到“某个 view 函数返回的字符串”或“某个方法返回的数值”。回执提供的是交易执行后的状态证据与日志等信息。仅仅因为浏览器页面把调用解码结果展示在回执附近，也不能据此认定那是标准回执本身包含的字段。

`returnData` 出现在哪里

Geth 的 eth 命名空间文档把 returnData 与回执字段分开描述。在该客户端所述的调用/执行结果语境中，成功调用可有返回数据；执行失败时 returnData 为空，revert 数据可能出现在错误数据中。这是 Geth 文档描述的接口语境，不能泛化为“所有以太坊标准回执都带有 returnData”。

如果你要检查 Solidity 调用返回数据，应确认采用的具体方法、客户端和请求参数。eth_call 是一种模拟执行调用的 RPC 路径；已确认交易回执则用于读取交易状态和日志。若想查看内部执行路径，可能需要客户端或服务商提供的 trace、simulate、debug 等扩展接口。它们的名称、访问权限和保留期限并非统一保证，必须按实际 RPC 服务文档核验。

从哈希到结果的核对顺序

确认查询网络与交易哈希。 先确认哈希对应的网络，避免跨网络查询导致的空结果。
查询 eth_getTransactionReceipt。 有回执后，先读区块信息与 status，确认交易所在位置和执行状态。
查看 Gas 与日志。 gasUsed 描述交易的 Gas 使用情况；logs 是执行产生的日志。需要解码时，使用与目标合约匹配的 ABI，并记住解码结论依赖正确的合约信息。
明确你缺少哪种数据。 如果要的是 Solidity 函数返回值，回执字段不是答案；如果要内部步骤，则要检查所用客户端是否提供相关 trace 或调试能力。
记录工具边界。 不同 RPC 提供者对扩展方法、历史数据及访问权限可能不同。没有具体交易哈希、客户端版本和接口响应，就无法判断某次浏览器展示背后调用了什么扩展。

读回执时不要越界推断

status 回答的是交易执行成功或失败，不代表某个应用的业务操作一定符合你的预期；事件日志记录的是日志，而非完整的全部执行轨迹；回执未返回也不等同于已失败；函数返回数据不能从标准回执字段凭空补出来。按问题选择接口，比盯着页面上某个“成功”徽标更可靠。

可继续阅读交易回执 status 为 1 就成功了吗？、交易回执里的 Logs 是什么？和以太坊 JSON-RPC 报文与节点交互，进一步区分状态字段、日志和调用方式。本文仅作技术信息说明，不构成投资或交易建议；执行签名交易前应核实网络、交易内容及合约地址，遇到客户端专有字段时以对应服务文档为准。