eth_getBlockByHash 怎么按哈希查区块？

什么时候需要按哈希查块

很多场景你手里只有「区块哈希」，没有「区块高度」：比如某笔交易详情里写着「所在块哈希」、某条事件日志附带了块哈希、或你在做对账时记录了一个历史块。这时用 eth_getBlockByHash 就能把整个块调出来，核对它的内容与状态。哈希是块的唯一指纹，比高度更可靠，尤其在发生重组时。

返回什么

该方法的返回体包含：块头（父块哈希、状态根、交易根、难度、gasLimit/gasUsed、时间戳、出块者等）以及该块里的交易信息。关键区别在于第二个参数：

• 传 false（或省略）：只返回块头与交易哈希列表，不展开每笔交易的明细，响应更轻。
• 传 true：额外展开块内每笔交易的完整字段，数据量大很多，适合需要逐笔核对时用。

按需选择，能显著减少带宽与解析成本，批量审计时尤其明显。

怎么调用

通过 JSON-RPC 发送 method 为 eth_getBlockByHash 的请求，params 里放两个值：区块哈希、是否展开交易（布尔）。节点返回对应块；若该哈希在链上不存在（例如你记错了、或该块已因重组被丢弃），会返回空。调用是只读操作，不上链、不花钱，可以频繁使用做交叉核对。

如何用核对「块是否真的在链上」

• 返回非空且字段自洽（父块哈希能对上、状态根/交易根格式正确）：说明这个块当前存在于你连接的节点视图里。
• 返回 null：可能哈希写错、节点未同步到该块、或该块已被重组淘汰。
• 对历史块做审计：把「当时记录的高度」与「现在按哈希查到的块」对比，能发现是否发生过重组，进而判断依赖该块的操作是否受影响。

常见误区

• 把「按高度查」与「按哈希查」混用：两者输入不同，前者用编号，后者用哈希；在重组后，同一编号可能对应不同块，而哈希是唯一的。
• 总是展开交易：在只需要块头时展开交易会拖慢响应、放大带宽。
• 忽略重组：低确认数的块哈希可能随后失效，判断「块是否最终」要结合确认数。

实战小记

按哈希查块，特别适合「手里只有一个哈希」的场景。比如你从某条通知里拿到一个块哈希，想确认它的内容，就可以直接用它查；再比如你在审计一段历史时，记录了某个关键块的哈希，事后想重新核对它的交易根、状态根是否对得上，也能用它。一个实用技巧是：查完之后，顺便记下这个块的父块哈希，再用父块哈希查一次，确认父子关系自洽，这样能进一步排除「孤立块」或「已重组块」的可能。把「块哈希 + 父块哈希 + 确认数」三者一起记录，你对这个块是否真正稳固在链上的判断就会非常扎实。

还要留意一个细节：按哈希查到的块，如果它的「难度」或「出块者」与你对这条链的预期不符，可能是连到了测试网或某个分叉。所以查块时顺便核对一下链的标识，能避免「查对了哈希、查错了链」的尴尬。把哈希当作跨链的唯一身份证来用，是它比按高度查更可靠的根本原因。

常见疑问一：查不到这个块是不是代表它不存在？不一定，也可能是节点未同步到该高度，或该块已因重组被淘汰，建议多节点交叉核对再下结论。常见疑问二：为什么有时候展开交易后数据特别大？因为展开后返回的是块内每笔交易的完整字段，块越大数据越多，只读块头时建议不展开。

风险提示

本文为信息与教育内容，不构成投资建议。不同节点同步进度与重组行为会变化，请以多节点交叉核对与对应链官方文档为准。