一、先明确“完整案例”的范围
区块链公链完整案例的设计文档怎么查，首先要明确查找目标：理解已有公链的技术架构，还是整理一份可供学习的案例分析。前者需要追踪协议与实现，后者还需要自行组织设计背景、模块关系和资料索引，不能把一篇介绍文章直接当成完整设计文档。
建议先列出问题清单：交易如何表示，节点如何验证数据，网络如何达成共识，状态如何保存，接口如何提供服务，协议如何升级。再逐项寻找对应资料，比只搜索“公链完整设计文档”更容易判断结果是否相关。
二、从两个技术文档入口建立索引
以太坊的 Nodes and clients 页面适合了解节点组成：执行客户端处理交易执行与状态，共识客户端负责权益证明共识相关职责；页面还列出执行规范、共识规范和 EIP 等进一步查阅方向。它是架构入口，并非覆盖整条公链的完整设计书。
比特币开发者指南的 Block Chain 页面适合梳理账本结构，涉及区块连接、UTXO、工作量证明和分叉等概念，可用于建立交易与区块验证的阅读框架，但不能代替网络、钱包与接口等其他主题的资料。
这两个入口分别是 https://ethereum.org/developers/docs/nodes-and-clients/ 和 https://developer.bitcoin.org/devguide/block_chain.html 。阅读时应区分项目，不要将两套体系的模块和规则直接拼接成同一个案例。
三、按主题逐层查找，而非只找白皮书
建议采用“项目文档入口—专题说明—协议规范—实现文档”的查找顺序。检索词可以由项目名称加主题组成，例如“Ethereum execution specs”“Ethereum consensus specs”“Bitcoin Developer Guide transactions”。这些是检索方向，不代表已经核验了搜索结果。
概述用于理解目标和模块，规范用于核对规则，实现文档用于了解具体软件行为。若需要解释某项设计的变化，再查看相关提案与升级说明，并核对其状态；不能仅凭存在一份提案，就认定它已经成为网络规则。
四、怎样判断案例资料是否完整
可建立一份资料目录，为每个主题记录文档标题、所属项目、适用版本、对应章节和待解决问题。目录至少覆盖数据结构、交易验证、共识、节点通信、状态存储与接口；若讨论运行维护，还应补充同步、配置和升级资料。
完整性应以问题是否得到回答为准，而不是文件数量或篇幅。资料未解释的部分应标注缺口；不同版本之间存在差异时，应保留版本边界，避免把旧版说明写成当前实现的确定行为。
五、适用条件与常见问题
这一路径适合已有公开技术文档的公链案例。只有宣传介绍、缺少协议说明或实现资料的项目，通常不足以支持完整的技术设计分析，应明确资料覆盖范围。
白皮书能否单独作为完整案例？不宜直接这样认定，还需检查具体规则与实现资料。节点教程能否替代设计文档？不能，运行方法与设计依据是不同问题。两个项目的材料能否相互补足？可以用于概念比较，但不能据此推断其中一个项目具备另一个项目的机制。