很多人对区块链区块的直觉印象是“一个装了很多交易的容器”。这个理解不算错，但不够完整。如果只把区块看成交易列表，就很难解释区块链为什么能防篡改、为什么节点能快速验证数据一致性，以及为什么不同链的区块看起来差别那么大。
这篇文章要回答的问题很具体：一个区块内部到底由哪些部分组成，这些部分各自承担什么功能，以及为什么“区块不只是交易”。
把区块拆开：区块头与交易列表
要理解区块的内部结构，可以先借助一个日常类比：把区块链想象成一本账本，每个区块就是账本中的一页。这一页上面有页首信息，比如日期、上一页的编号、本页内容的摘要；页首下方才是真正的账目记录。
真实的区块也是类似的两层结构：
- 区块头（block header） ：存放元数据，负责连接、验证和共识。
- 交易列表（transaction list） ：存放这个区块真正记录的用户操作或状态变更请求。
这里的“元数据”不是交易本身，而是关于这个区块的信息。它回答的问题是：这个区块是谁的前一页？这一页里的交易整体长什么样？这一页是什么时候打包的？它是否符合网络的共识规则？
这个“元数据 + 内容”的结构是理解区块内部的关键。区块头像身份证和连接器，交易列表才是账本正文。
需要说明的是，这个类比有明确的局限。账本不会自动通过密码学互相锁定，而区块链的哈希链接是密码学层面的强绑定，不依赖人工核对。类比帮助我们建立两层结构的直觉，但不能替代后面的机制解释。
区块头：这一页的身份证和连接器
区块头里通常包含几类关键字段。下面以比特币的区块头结构为例，展示一个简化视图。这不是所有区块链的通用模板，但能帮助我们看到区块头字段各自在做什么。
一个简化的比特币区块头通常包含：
- 版本号
- 父区块哈希（previous block hash）
- Merkle root（交易根）
- 时间戳（timestamp）
- 难度目标（difficulty target）
- nonce
这些字段看起来零散，其实可以按功能分成三组来理解：连接、验证、共识。
父哈希：把当前区块指向前一区块
父区块哈希记录的是前一个区块的哈希值。哈希函数可以把任意数据映射成一个固定长度的指纹，相同数据得到相同指纹，数据一变指纹就变。
父哈希的作用就是让当前区块“记住”前一区块的指纹。这样一来，每个区块都指向前一个区块，形成一条从后往前的链。如果前一个区块的内容被改动，它的哈希就会变化，当前区块记录的父哈希就对不上。这种链式引用是区块链防篡改的基础之一。
Merkle root：把一组交易压缩成一个指纹
区块头里不会直接列出所有交易，而是放一个 Merkle root。Merkle root 是把交易列表经过特定结构逐层哈希后得到的单一根哈希值。
它的关键作用是：用一个小指纹代表整组交易。交易列表中任何一笔交易发生变化，Merkle root 都会随之改变。这样区块头就能绑定交易列表的完整性，而不需要在头部重复存储每一笔交易。
这里不需要深入 Merkle 树的完整构造和证明生成过程。对理解区块内部结构来说，只需要知道：Merkle root 是交易列表在区块头中的“摘要代表”。
时间戳、难度和 nonce：为共识服务
时间戳记录区块的大致打包时间，但不同链对时间精度和可接受范围的验证规则不同，不能把某条链的规则当作通用标准。
在比特币这类工作量证明（PoW）链中，区块头还包含难度目标和 nonce。矿工需要找到一个 nonce，使得区块头的哈希满足当前难度目标。nonce 本质上是一个让矿工可以反复尝试的变量，难度目标则定义了“多难才算合格”。这两个字段服务于挖矿证明和共识校验，而不是记录用户交易。
需要强调：nonce 和难度目标是特定共识机制下的设计。其他共识机制的链可能有完全不同的字段。例如以太坊在转向权益证明（PoS）之后，区块结构发生了变化，不再像比特币那样依赖传统 nonce 挖矿，区块头中还会包含状态根、交易根、收据根以及 gas 相关字段等。以太坊的具体字段随协议版本演进，准确了解应查阅其协议文档。
这里只把状态根作为一句背景带过：某些链需要把链上状态的摘要也放进区块头，用于验证状态一致性。状态树的具体构造不属于本文范围。
交易列表：区块真正记录的一批事件
交易列表是区块的内容部分。交易代表用户发起的操作，比如转账、调用智能合约，或者更一般地说，是对链上状态的一次变更请求。
一个区块通常会打包多笔交易，而不是每笔交易单独占一个区块。这样做的好处是提高吞吐效率：把多笔操作集中在一页里，比每笔操作单独成页更经济。不同链对交易内容、排序方式和执行方式的定义可能不同，但“区块包含一组交易”是多数链的共同做法。
交易列表与区块头之间通过 Merkle root 绑定。可以想象一个简化场景：一个区块里打包了三笔交易，Tx1、Tx2、Tx3。它们经过逐层哈希后得到一个 Merkle root，记为 R。这个 R 被写入区块头。如果其中任何一笔交易被改动，重新计算得到的根就会变成 R’，与区块头中记录的 R 不一致。
这就解释了为什么区块头虽然不是交易内容，却能帮助网络验证交易列表没有被篡改。
区块哈希如何把交易和链绑在一起
现在可以回答一个关键问题：为什么改了区块里的一笔交易，后面的链就会出问题？
这需要理解三个角色的关系：区块哈希、Merkle root 和父哈希。
区块哈希是对区块头求哈希
在比特币等链中，区块哈希通常是对区块头进行哈希计算得到的标识，而不是直接对交易列表求哈希。这个细节很重要，因为它决定了交易是以间接方式影响区块哈希的。
交易列表先经过 Merkle root 被压缩成一个指纹，写入区块头；然后区块头整体被哈希，得到区块哈希。所以交易变化会先改变 Merkle root，再改变区块哈希。因果方向是：交易 → Merkle root → 区块头 → 区块哈希。
如果把因果方向说反，认为“区块哈希直接由交易内容算出”，就会遗漏区块头中其他字段的作用，也无法准确解释父哈希的链式关系。
父哈希让链式防篡改生效
每个区块的区块头都记录前一个区块的哈希。假设攻击者修改了第 9 个区块里的一笔交易。这笔交易变化会导致该区块的 Merkle root 变化，进而导致第 9 个区块的区块哈希变化。第 10 个区块的区块头中记录的父哈希是第 9 个区块原来的哈希，现在对不上。如果要让第 10 个区块继续有效，攻击者必须修改第 10 个区块的父哈希，这又会改变第 10 个区块的哈希，进而影响第 11 个区块，以此类推。
这就是链式绑定的效果：改动越早，需要重新计算的后续区块越多。
不可篡改是计算上的，不是绝对的
这里需要纠正一个常见但过于绝对的说法：区块链内容“绝对不可篡改”。
更准确的表述是：篡改会破坏后续区块的父哈希和 Merkle root 匹配，因此很容易被节点发现；但在某些共识机制下，如果攻击者掌握足够算力，仍可能发生链重组。所以区块链的不可篡改性更准确地说是计算上、概率性的难以篡改，而不是逻辑上绝对不可能更改。理解这一点，才能对区块链的安全边界有合理预期。
不同区块链，不同的区块内容
一个容易产生的误解是：所有区块链的区块结构都一样。实际上，不同链的区块字段可能差异很大。
比特币和以太坊的区块头字段就不同。比特币的区块头相对精简，包含版本号、父哈希、Merkle root、时间戳、难度目标和 nonce 等字段。以太坊的区块头则包含父哈希、状态根、交易根、收据根、gas 相关字段、时间戳等，并且在合并升级后区块结构有所变化，不再依赖传统 PoW nonce。
即使都采用“区块头 + 交易列表”的类似概念，不同链对交易排序、执行方式、状态记录的定义也可能不同。一些链可能使用不同的数据结构，但多数仍保留类似的两层划分。
要准确了解某条链的区块结构，应查阅该链的协议文档，而不是把某条链的字段列表当作所有区块链的通用模板。
快速回顾：一个区块的完整心智模型
到这里，可以把区块的内部结构收束成一个可以记住的模型：
- 区块 = 区块头 + 交易列表。区块不是单纯的交易集合。
- 区块头是元数据，负责连接前一区块、绑定交易完整性、参与共识校验。
- 交易列表是内容，记录用户操作或状态变更请求，一个区块通常打包多笔交易。
- Merkle root 连接交易列表和区块头，任何交易变化都会改变 Merkle root，进而间接改变区块哈希。
- 父哈希连接当前区块和前一区块，使篡改容易暴露，形成链式防篡改结构。
- 区块哈希通常是对区块头求哈希，交易通过 Merkle root 间接影响区块哈希。
- 具体字段因链而异，尤其是 PoW 链与 PoS 链之间，不能把某条链的设计当作所有区块链的通用结构。
如果只记一句话：区块头负责“连接和验证”，交易列表负责“记录内容”，Merkle root 和父哈希把这两层以及整条链绑在一起。理解了这个结构，再看到不同链的区块浏览器页面时，就能分辨哪些字段是元数据、哪些是实际交易，也不会再把区块误认为只是一个交易列表。
