eth_sendRawTransaction 怎么广播已签名交易？

什么是「原始交易」

原始交易（raw transaction）是「已经用私钥/设备签好名、但还没上链」的一串十六进制数据。它包含了交易的全部字段（收款、金额、nonce、gas、签名等），只差「被广播进网络」这一步。硬件钱包、离线签名流程产出的就是这种形态——签名在离线环境完成，最后才把成品提交上链。理解「已签名未上链」这个状态，是理解整个流程的关键。

为什么需要 eth_sendRawTransaction

普通钱包点「发送」时，内部其实也做了「构造 → 签名 → 广播」。但在以下场景，你会显式地广播一个已签名交易：

• 硬件钱包 / 离线签名：签名在设备内完成，拿到 raw 后提交。
• 多签 / 聚合签名：把多方签名合并后广播。
• 脚本 / 自动化：程序化地把一批已签名交易推上链。

eth_sendRawTransaction 的作用，就是把这个签好的包提交给节点，让节点验证后放入内存池、等待打包。

怎么提交

通过 JSON-RPC 发送 method 为 eth_sendRawTransaction 的请求，params 里放一个值：签名后的原始交易十六进制串。成功时，返回这笔交易的哈希；之后你可以用 eth_getTransactionByHash 跟踪它是否被打包。整个提交是「一次性」动作：一旦提交成功，交易进入内存池，就进入正常打包流程。

提交失败的常见原因

• 格式错误：原始交易不是合法的十六进制，或版本/链不匹配（主网签的交易发到测试网）。
• nonce 不匹配：交易的 nonce 不是账户下一个期望值，节点会拒绝。
• 余额不足：连 gas 都付不起，无法被接受。
• 费用过低：节点可能因策略不接收明显低于网络水平的交易。
• 节点未同步：节点落后，验证不出当前状态。

与硬件钱包流程怎么对应

典型流程：在钱包里「构造交易」→ 设备「签名」→ 导出 raw → 通过 eth_sendRawTransaction 广播 → 用交易哈希在浏览器确认打包。每一步都要核对 chainId、nonce、收款地址，任一步错都会导致失败或打错地址。建议在广播前用浏览器把 raw 解码核对一遍，再提交。

实战小记

离线签名加广播，是「安全」和「可用」之间的一种平衡。把私钥留在离线环境里签名，能避免它接触联网设备；签名完成后再把成品广播，既保护了密钥，又完成了上链。理解这个分工，你会明白为什么硬件钱包、冷钱包、离线签名工具都采用「构造在联网侧、签名在离线侧、广播回联网侧」的流程。一个容易被忽略的安全细节是：广播前一定用浏览器或解码工具把 raw 交易解码看一眼，确认收款地址、金额、chainId 都对，再提交。因为 raw 是一串不可读的十六进制，肉眼看不出错，必须解码核对。把「解码核对」这一步固化进流程，能挡住绝大多数「签对了、发错了」的隐患。

另外，广播这一步本身是「把已签名的包交给网络」，它不会改变交易内容，所以广播用的节点只要连通即可，不需要一定是「最安全」的节点。但要注意别把 raw 发到错误链的节点上，因为 raw 里编码了 chainId，发错链会被拒绝。把「签名在离线、广播在联网」的职责分清楚，并保留好「广播前解码核对」这一步，整个离线签名流程就既安全又可靠。

常见疑问一：广播失败会不会把签名泄露？不会，广播失败只是节点没接受这笔交易，raw 仍在你手里，你可以改参数重新签名或换个节点再广播。常见疑问二：为什么一定要「解码核对」再广播？因为 raw 是不可读的十六进制，只有解码成人类可读字段，才能确认收款地址、金额、chainId 都没错，这是防止「签对了、发错了」的最后防线。

风险提示

本文为信息与教育内容，不构成投资建议。原始交易一旦广播无法撤回，务必在广播前核对收款地址、chainId 与金额；不同链的 raw 格式与 RPC 行为有差异，请以对应链文档为准。