先区分存储、验证与查询
讨论区块链的数据存储，需要分别回答三个问题：数据保存在哪里、如何判断数据符合规则、需要时能否取得。三者相关，但不是同一件事。节点能够验证某类数据，不代表它会永久保留这些数据，也不代表它可以立即回答所有历史查询。
误区一：全节点就是永久保存全部历史状态
以太坊节点文档区分了全节点、归档节点和轻节点。全节点可以采用裁剪策略减少本地存储；归档节点侧重保留历史状态，适合查询过去某个区块时的账户状态。轻节点则以较少的本地数据配合外部数据和证明完成验证。
因此，“全”不能简单理解成“什么都永久保存”。例如，查询当前余额与查询很久以前某个区块时的余额，对本地数据和查询能力的要求并不相同。选择节点类型，应先明确需要当前状态还是历史状态。
误区二：有区块头，就有全部交易内容
比特币技术文档将区块头与交易数据分开描述。区块头包含前一区块头的哈希和交易的默克尔根，用于关联区块并约束交易内容，但它本身不是全部交易记录。
可以把这种区别理解为“校验依据”与“被校验内容”的区别。拥有摘要，不等于拥有原始内容；不能因为保存了区块头，就认为本地已经保存了该区块中的所有交易。
误区三：数据可验证，就一定随时可取得
验证解决的是取得的数据是否与可信的校验依据一致，存储与服务则决定数据能否被提供。轻节点需要向其他节点请求额外信息，正说明验证能力与数据供应存在不同职责。
因此，判断查询能力不能只问“能不能验证”，还要问“谁保存了需要的数据”。第三方接口能够提供访问入口，但接口本身不能替代底层的数据保存。
误区四：裁剪数据等于修改链上历史
裁剪是本地存储策略，修改历史则涉及改变已经记录的内容，两者不能混为一谈。节点不再保留某些旧数据，并不意味着这些记录在协议意义上被改写。
同样，也不应承诺被裁剪的数据总能立即恢复。历史状态是否可重建、重建需要哪些数据，以及是否支持直接查询，都要结合客户端和保留策略判断。
常见问题：不同区块链能否套用同一存储结论
不能直接套用。以太坊的历史状态保存与比特币的区块结构可以帮助理解概念，但不能据此认定所有区块链具有相同的节点分类、裁剪方式或查询能力。
实际判断时，应核对三个条件：保存的是区块、交易还是状态；需要的是当前查询还是历史查询；数据来自本地还是外部服务。把这些条件说清楚，比笼统地说“区块链永久存储一切”更准确。