先分清节点与客户端
节点是运行区块链客户端、连接网络的实例；客户端是执行协议规则的软件。理解节点类型，可以先问三个问题：它自己验证哪些数据，保存哪些历史信息，承担什么网络职责？这三个维度可以重叠，不能把所有名称当作互斥选项。
以太坊开发文档将执行客户端与共识客户端区分开：前者处理交易执行和状态，后者处理权益证明共识；验证者软件承担额外的共识职责。全节点、归档节点和轻节点则体现不同的数据处理方式。
全节点与归档节点：验证和保存是两件事
全节点的关键能力是按协议验证数据。“全”不意味着必须永久保存每个时点的全部状态。理解存储需求时，应区分区块中的交易记录与交易执行后形成的账户状态；保留其中一种，不代表另一种也能直接查询。
归档节点保留历史状态，适合需要反复查询过去账户状态的服务。以太坊文档中的归档用途包括历史余额查询和链上分析。判断是否需要归档能力，重点在于查询是否涉及历史状态，而不是简单认为存储越多就越适合所有应用。
轻节点与SPV：证明能够说明什么
轻量验证通过较少的数据和密码学证明减少本地处理负担。比特币开发指南介绍的SPV使用区块头与默克尔证明，核实交易是否被某个区块收录，并参考累计工作量评估链；它并不完整验证区块内所有交易的有效性。
因此，“交易被收录”与“交易满足全部规则”是不同判断。轻量方案适合资源受限且接受其验证边界的场景，还需考虑数据提供方遗漏信息、网络连接受限及查询暴露隐私等问题。不同链的轻客户端设计不同，不能直接套用同一安全结论。
适用条件与常见问题
需要独立核验规则时，关注全节点的验证能力；需要频繁查询历史状态时，关注归档能力；设备资源有限时，则需了解轻量方案具体核验什么、依赖谁提供数据。评估资源时，应同时考虑存储、带宽和计算负担。
运行节点就等于成为验证者吗？不等于。核验网络数据与承担提议区块、投票等职责需要分别理解。同步方式是否也是节点类型？同步描述如何获得并追上链的数据，不能只凭同步名称判断长期保存范围或网络角色。
钱包是否就是轻节点？应看其实际验证机制。连接远程接口并显示余额，并不能单独证明钱包会校验区块头或密码学证明。入门时，先确认验证边界，再理解存储与职责，更容易看清各类节点的区别。