区块头首先是链接与摘要
在比特币开发者指南里，每块会保存前一块头部的哈希，从而把块串成链；交易先两两哈希形成默克尔树，最终的默克尔根写入区块头。这样，改动任一已确认交易都会迫使后续祖先哈希与区块头一并变化，成本不再只是“改一行账本”。
以太坊文档同样把块描述为带有父块哈希的交易批次：新块严格引用父块，块内交易也有顺序。核验区块头时，先对齐的是“它声称接在哪一块之后”，而不是浏览界面上的涨跌摘要。
比特币：工作量证明哈希的是头部
比特币的工作量证明要求对区块头做哈希，结果必须不高于当前难度目标；指南写明哈希对象主要是约 80 字节的头部，并提供 nonce 等易改字段以便重试。交易数据变多并不会按比例拖慢这次哈希，因为完整交易列表不在被反复哈希的头部里，而是通过默克尔根被摘要进去。
因此，看到“块哈希已满足难度”只能说明该头部在共识规则下可被接受为候选工作量证明结果；它还不自动等于你已下载并逐笔执行了块内全部交易。SPV 场景里，客户端可凭头部中的默克尔根与中间哈希检查某笔交易是否被包含，但开发者指南也提醒：包含证明昂贵地约束造假，却不等于全节点那种完整有效性校验。
以太坊：执行摘要字段要对照读
以太坊“块里有什么”一节区分了共识侧结构与 execution payload / execution_payload_header。头部类摘要会列出 parent_hash、state_root、transactions_root、收据相关根、gas_used 与 gas_limit、时间戳等。这些字段用于概括执行结果与资源边界，而不是替你展示每一笔调用的业务含义。
核验时常见误区是把浏览器上的“已出块”直接读成“我关心的合约状态已按某口径最终确认”。更稳妥的读法是：先确认父哈希链接与摘要根对应哪一执行视图，再决定是否需要全节点或可验证索引服务去展开交易列表与状态。
核对边界
把“区块链 区块头”当成核验词时，优先核对三件事：前块/父块哈希是否把顺序钉死、默克尔根或交易根是否真能支撑包含/完整性主张、以及工作量证明或执行摘要到底覆盖了头部还是整块数据。不要用搜索摘要里的科普标题替代开发者文档中的字段定义。