先拆分“垃圾回收”这个关键词
“垃圾回收”在区块链语境中可能指向几类不同问题：一是节点或客户端使用的编程语言如何回收内存；二是执行引擎中的临时内存如何在一次交易结束后释放；三是节点是否保存历史区块、状态或索引数据；四是智能合约如何清理自身的持久化存储。这些概念的对象、生命周期和负责组件并不相同，不能用一个关键词直接代替。
如果目标是研究客户端性能，应搜索“garbage collection”“memory management”“execution client”；如果关注链上状态，应搜索“state storage”“state pruning”“history data”；如果关注EVM执行过程，则应搜索“EVM memory”“transient storage”“contract storage”。检索前先写清楚对象、生命周期和预期结果，通常比直接搜索“区块链垃圾回收”更有效。
从EVM文档确认执行层的边界
以太坊EVM文档把以太坊描述为一种分布式状态机：交易输入经过确定性的状态转换，产生新的状态。文档还区分了三种容易混淆的存储区域：执行期间使用的内存、交易期间可在内部调用间共享的临时存储，以及属于合约账户并写入全局状态的持久化存储。
这一区分可作为阅读设计文档的基本坐标系。EVM内存不会在交易之间持久存在；临时存储在同一交易的内部调用间保持可用，但交易结束后清除；合约持久化存储则属于账户状态的一部分。由此可见，讨论“回收”时必须先说明是在执行帧、单笔交易、合约状态，还是节点本地数据层发生。EVM文档能够帮助读者理解执行语义，但它本身并不等同于某个客户端的内存垃圾回收设计。
从Bitcoin开发者指南定位协议与实现文档
Bitcoin开发者指南按区块链、交易、钱包、合约、支付处理、运行模式、点对点网络、挖矿和RPC等主题组织内容。它适合用来建立协议开发的检索入口：先判断问题属于数据结构、交易处理、节点运行还是网络通信，再进入相应章节或继续查找具体实现的规范。
如果问题是节点如何管理本地数据，不能仅凭“区块链开发指南”这一总入口得出具体的清理策略。应继续寻找对应客户端的运行参数、数据目录说明、存储层设计和测试材料，并核对这些内容适用于哪个版本或实现。协议规则、客户端实现和操作运维文档是三个层级，结论必须标明所处层级。
一套可复用的设计文档检索流程
第一步是定义问题：例如“交易执行完成后哪些数据仍然存在”“节点能否删除某类历史数据”“客户端的内存由哪一层管理”。第二步是建立术语表，把“垃圾回收”拆成内存管理、临时存储、状态裁剪、历史数据保留和合约存储清理等词。第三步优先查官方协议规范、虚拟机说明和开发者指南，再查具体客户端的实现文档。
第四步按生命周期画出边界：区块、交易、内部调用、执行帧和节点本地数据库分别何时创建、何时更新、何时结束。第五步记录每条结论的适用对象，例如“EVM语义”“某类节点实现”或“某种编程语言运行时”，避免把通用机制误写成整个区块链网络的统一行为。第六步用测试说明、代码注释或版本文档交叉核对，特别是涉及删除、裁剪和数据恢复的结论。
适用条件与常见误区
这套方法适合查找区块链执行引擎、节点存储和开发规范类资料，尤其适合关键词含义宽泛、不同资料使用不同术语的情况。它不适合直接推断某个客户端当前版本的性能、磁盘占用或数据保留策略；这些问题需要对应实现的版本化文档或源码依据。
常见误区包括把EVM临时存储当作编程语言垃圾回收，把删除本地历史数据当作链上状态被删除，以及把合约存储清理等同于节点释放内存。另一个误区是只看概念介绍，不确认资料描述的是协议强制规则、客户端选择，还是开发者自行设计的应用逻辑。
常见问题
问：查“垃圾回收”应从EVM还是Bitcoin文档开始？答：取决于问题对象。涉及智能合约执行、内存和存储生命周期时，可先看EVM相关说明；涉及区块链协议、交易、节点运行和网络组件时，可从Bitcoin开发者指南这类分类入口开始。两者不能互相替代。
问：交易结束后所有数据都会被回收吗？答：不能笼统这样说。EVM文档明确区分交易期间的临时存储、执行内存和持久化合约存储；它们的生命周期不同。至于节点本地数据库中的历史数据，还要查看具体客户端和配置的文档。
问：怎样判断一篇设计文档是否足够可靠？答：检查它是否明确组件、生命周期、状态边界、版本和适用范围，并确认关键结论能在协议规范、实现文档或可复现测试中找到对应依据。只写“区块链会自动清理垃圾”而不说明清理对象和触发条件的材料，通常是不完整的。