交易回执status为1就成功了吗？ 图 1
交易回执status为1就成功了吗？ · 图 1

交易回执的 status=1 只说明 EVM 顶层执行没有回滚，不代表用户业务一定达成。合约可能捕获内部失败、返回 false、发出意外事件，或把资产送到错误对象；因此 inclusion、execution 与 business outcome 必须分层验收。

回执的status只回答哪件事

  1. null、0 和 1 是三种状态：eth_getTransactionReceipt在交易尚未包含时可返回null，包含后返回区块位置、gasUsed、日志和状态等字段。
  2. Gas 字段如何复算：status为0表示EVM执行失败，仍可能消耗Gas；status为1表示执行未回滚，但不保证应用业务目标正确。
  3. Logs 是业务验收入口：logs与contractAddress需要按交易类型解释，确认数还要结合blockHash及safe或finalized链头判断。

null、0 和 1 是三种状态

null 常表示交易尚未被当前节点纳入或不可见；status=0 表示执行失败且状态回滚，但 Gas 仍消耗；status=1 表示顶层成功。确认数需要用 receipt.blockHash 与当前 safe/finalized 链头比较，不能把拿到回执就叫最终。

从交易执行核对到业务结果

  1. 先确认交易 hash、chainId、from、to 与预期一致。
  2. 读取 receipt 并固定 blockHash，分别记录 status、gasUsed、effectiveGasPrice。
  3. 用 ABI 解码目标事件，核对日志地址和业务字段。
  4. 等待业务要求的 safe/finalized 层级，再复查余额或状态。

Gas 字段如何复算

gasUsed 是该交易实际使用量，effectiveGasPrice 是按交易类型和区块费用规则得到的每 Gas 价格；两者相乘得到执行费用主体。还要区分 L2 额外数据费或协议费，不能把一个链的 receipt 字段解释套到所有网络。

没有目标事件就别宣布完成

ABI、目标合约或事件验收条件不明时，不能仅凭 status=1 触发下一笔资金动作。

Logs 是业务验收入口

按合约地址与 event signature 解码 logs，核对 indexed topics、data、数量和接收方。代理调用时日志地址通常是 proxy；内部合约返回 false 却被调用方吞掉时，status 可为1，必须结合事件、余额或状态 getter 判断。

外层成功但内部失败时

一次 ERC-20 调用可能 status=1，却没有目标 Transfer 事件，或事件金额与预期不同。前端应显示“链上执行成功但业务结果待核验”，而不是统一弹出“转账成功”。

把技术成功与业务成功拆开

支付或业务系统应把交易执行和业务结果分层建模。回执成功后，继续检查预期合约地址、事件主题、金额、收款方和必要的状态变化；回执失败则保存 revert 数据并避免把已消耗 Gas 说成“交易不存在”。对于多调用合约，还要确认原子性设计：外层成功可能包含被捕获的内部失败，只有业务事件和状态才能回答目标动作是否完成。

交易回执字段的规范来源

  1. ethereum.org JSON-RPC：用于核对eth_getTransactionReceipt的候选主题的一手字段、产品说明或事件发现。
  2. Ethereum Execution APIs：用于核对eth_getTransactionReceipt的实现路径、交叉验证或风险边界。

相关站内主题：交易解码、确认与最终性。资料访问时间为2026-07-22；协议、接口、监管清单与产品界面均可能更新。

风险提示：status为1只证明外层交易没有回滚，不能替代业务事件、目标地址和余额变化核验。多调用合约可能捕获内部失败；涉及付款或结算时应建立额外验收条件，本文不保证某笔交易的商业结果。