先把问题拆成技术模块
“区块链的支撑技术的设计文档怎么查”首先需要明确查什么：身份验证关注密钥与签名，数据组织关注区块、哈希与树结构，交易有效性关注账户状态或交易输出，共识则关注节点如何验证和选择历史记录。
建议将检索条件写成“网络名称＋技术模块＋具体问题”。例如，查询账户如何表示，与查询区块如何连接，所需文档并不相同。不要只搜索“区块链设计文档”，否则容易把不同网络、不同层次的说明混在一起。
用开发者指南定位术语
以太坊开发者文档的 Accounts 页面介绍账户类型，并解释 nonce、balance、codeHash、storageRoot 等字段，也区分账户与钱包。这类内容适合作为账户模型、签名和状态存储的阅读入口，但不能仅凭一页概念说明还原完整协议设计。
比特币开发者指南的 Block Chain 页面说明区块头通过前一区块头的哈希连接，交易通过默克尔树汇总，并介绍未花费交易输出、工作量证明及分叉选择。它适合帮助定位数据结构、交易验证和链选择问题。
从概念页面追到设计细节
阅读时可按“术语解释—规则描述—实现核对”的顺序推进。先弄清对象是什么，再记录有效性条件、字段含义和处理流程；如果问题涉及程序行为，再寻找与该规则对应的实现说明或代码位置。
把文档中的英文术语保留为检索词，例如 storageRoot、UTXO、merkle root。每次围绕一个问题检索，如“这个字段表示什么”或“节点据什么拒绝交易”，比同时追查所有底层技术更容易形成清晰结论。
判断文档是否适用
核对材料所指的网络、模块和适用版本，并区分它是在解释原理、定义规则，还是介绍某个实现。若缺少版本或适用范围，不宜直接用来判断特定部署的行为。
整理时可以记录文档标题、章节、关键术语、适用范围和未解决问题。两个来源的价值在于帮助辨认不同技术路线，而不是把不同网络的规则拼成一份通用规范。
常见问题与阅读边界
账户文档能否代替完整设计文档？不能。它只能回答相关模块的问题，不能替代共识、网络通信等部分的说明。看到“nonce”也不能默认含义相同，应结合所在章节辨认。
哈希连接是否意味着数据绝对不能修改？不应这样理解。需要同时考察验证规则与共识机制。查阅设计文档的目标，是明确系统在什么条件下成立、如何处理冲突，而不只是记住“不可篡改”等概括性表述。