eth_sendRawTransaction 与读调用

一次合约读取和一次链上交易，可能都从应用界面上的“调用”按钮开始，但它们对区块链的影响完全不同。判断时不要只看函数名称或页面有没有显示结果，先确认请求使用的是 eth_call 还是 eth_sendRawTransaction：前者让节点在某个区块状态上执行一次调用并返回结果，不创建链上交易；后者接收已经签名的原始交易并提交，返回交易哈希，并不代表合约已成功执行。

先看请求到底做了什么

eth_call 的关键特征是“在选定状态下立即执行”。常见用途是读取合约 view 或 pure 函数的返回值。开发者可以指定某个区块号，也可以使用 latest、pending、safe、finalized 等区块标签。它适合回答“按照节点当前所见的这个状态，调用会返回什么”，但本身不会创建待打包交易。

eth_sendRawTransaction 的输入则是已经签名的原始交易数据。调用这个方法是在把交易提交给节点，RPC 通常返回交易哈希；规范也描述了交易尚不可用时的零哈希情形。哈希是后续查找这笔交易的标识，不是合约函数的返回值，也不是执行成功证明。

对照项	eth_call	eth_sendRawTransaction
主要输入	消息调用参数及区块状态标签	已签名原始交易数据
发生的事	节点按指定状态执行调用	节点接收并提交交易
是否创建链上交易	否	提交的是待纳入区块的交易
直接返回	调用执行结果	交易哈希（特定情形可能是零哈希）
能否据此断定交易成功	不适用	不能，须继续查回执

为什么读取结果不等于随后交易结果

区块标签不是装饰信息，而是调用所依据的状态位置。以 latest 查询到的结果，回答的是节点所选最新区块状态下的执行结果；如果随后才广播交易，链上状态可能已经变化。因此，同一笔交易相关的预估或读取调用，不能保证之后上链时会得到完全相同的执行条件或结果。本文不提供特定服务商的历史状态查询能力、限流或错误格式保证，这些属于各 RPC 服务的差异范围。

反过来，交易哈希也只告诉你提交请求对应的识别值。交易仍需要被验证者纳入区块。若要核对已纳入交易的执行状态，应使用 eth_getTransactionReceipt 查询回执，并阅读其中的状态信息；哈希返回之后暂时没有回执，不能单独作为执行成功或失败的结论。

一条可复核的查询路径

第一步：读取前确定状态口径。 记录调用节点和区块标签。查看合约读取结果时，明确它是哪个网络、哪个状态下的输出；若代码或界面隐藏了状态参数，不要把它默认理解成永远最新。

第二步：提交前区分模拟与签名。 eth_call 用于执行消息调用，不等于签署并广播交易。真正提交时，检查客户端生成的是已签名原始交易，再确认发送方法确实是 eth_sendRawTransaction。签名意味着授权这笔具体交易被提交，不能把它和只读查询混为一谈。

第三步：保存哈希并查询回执。 提交方法返回后保存交易哈希，随后用 eth_getTransactionReceipt 核对是否已有回执及其状态。若还没有回执，现有证据只说明请求得到某个 RPC 响应，传播范围、是否进入其他节点交易池、最终确认时间仍未知。

第四步：把执行输出与回执分开看。 调用返回的数据、交易哈希、回执状态和事件日志分别回答不同问题。需要更多执行细节时，必须核对当前客户端或 RPC 服务实际支持的接口，不能假设每个公共节点都开放相同的 trace 或调试能力。

常见混淆与边界

把 eth_call 的成功响应当成交易已完成，是最常见的层级混淆：调用只是在给定状态上执行，不会自动生成交易。把哈希当成执行结果也不准确：哈希用于定位交易，最终状态要看回执。还有一种误读是认为预执行结果能保证广播后成功；但状态可能在两次操作间改变，官方 RPC 定义并没有给出这种保证。

排查时可以先问三个问题：请求方法是什么？调用采用哪个区块状态？如果这是已提交交易，回执是否已经出现、状态字段是什么？这样能把“读取没有写入”“已提交但等待纳入”与“已有回执但执行失败”分开。具体服务的错误提示、历史状态保留和传播行为不在本文事实范围内，遇到它们应查询相应服务商文档。

继续阅读以太坊 JSON-RPC 报文与节点交互、交易回执（receipt）里有什么？和以太坊交易回执怎么看？，可分别了解请求结构和回执字段。本文仅解释协议接口及核验方法，不构成投资建议或交易建议；任何实际签名与广播都应由操作者核对网络、交易内容和接收对象后自行决定。