误区一：直接套用同一种数据模型
区块链数据挖掘是对链上记录进行整理、关联和分析。选择统计或图分析方法前，需要先明确记录代表什么。比特币开发指南描述了交易输入对既有输出的引用关系；以太坊 JSON-RPC 文档则区分状态查询与历史记录查询。
分析交易关联时，应明确图中的节点代表交易、输出还是账户；分析余额时，应明确状态对应的时点。模型定义不同，同名指标也可能具有不同含义，不能只凭字段名称合并结果。
误区二：把接口返回当作完整样本
以太坊文档区分执行客户端接口、共识客户端接口，并提示客户端支持情况可能存在差异。能够连接节点，并不意味着一个接口覆盖所有研究对象。
采集方案应先限定网络、数据类别和查询范围，再检查返回内容是否符合预期。遇到错误、空结果或字段缺失，应分别记录，不能统一填成零值，否则会把采集问题混入统计结果。
误区三：混用查询时点和编码类型
以太坊状态查询的区块参数决定查询位置，latest、pending、safe、finalized具有不同含义。文档还区分十六进制数量与字节数据，两者的格式要求不同。
比较多次查询结果时，应固定可复核的区块位置，避免把查询期间的状态变化解释为样本差异。解析字段时则应保留类型信息：数量可参与数值运算，地址与哈希需要保持其标识含义，不能统一按普通整数处理。
误区四：认为区块高度能唯一定位记录
比特币开发指南指出，分叉期间可能存在高度相同的不同区块，因此区块高度不能作为全局唯一标识。
建立数据索引时，应结合所属网络和区块哈希保存记录身份，并保留高度用于排序。持续采集链头数据的场景，还需要核对记录所属分支，避免把不同分支的数据重复计入同一份统计。
常见问题：验证通过是否意味着解释正确
比特币的默克尔证明可用于核验交易是否被包含在某个区块中，但这种验证本身不能说明交易的现实业务目的。记录存在、关联成立和业务解释正确，是不同层次的问题。
描述性统计适合回答限定样本中发生了什么；关联分析适合发现结构关系。若要进一步解释身份、意图或因果关系，需要额外证据。报告应交代样本范围、字段口径、缺失处理和验证边界，使结论能够被复核。