误区一：把不同查询对象统称为源码
“区块链源码”容易混指节点软件代码、智能合约源码和链上交易数据。查询前应明确对象：要理解程序实现，还是核对某个合约的部署代码，或查找一笔交易？这些目标需要不同证据，交易数据不能替代程序源码。本文重点解释以太坊合约验证与比特币交易查询的边界。
误区二：公开了代码，就代表与链上一致
以太坊开发文档说明，源码验证用于核对公开源码编译后的字节码与目标合约是否匹配。仅看到代码文件，还不能建立这种对应关系；编译器版本、优化设置等也影响结果。适用范围是具体合约及其编译条件，不能据此推断整个项目的代码都已得到核对。
误区三：验证通过，就代表逻辑安全
源码验证确认代码对应关系，形式化验证则针对行为是否满足预期性质。二者回答的问题不同。阅读时应区分“部署了什么代码”与“代码能否正确工作”：验证标签本身不能证明没有漏洞，也不能替代对权限和业务逻辑的检查。
误区四：忽略匹配范围，直接相信注释
注释或部分变量名的差异可能不改变执行字节码。因此，代码匹配不意味着注释中的承诺得到验证。以太坊文档介绍的完整验证，还利用元数据哈希核对源文件和编译信息。判断结果时，应看清是否包含这种核对，避免把部分匹配理解为源文件逐字一致。
误区五：把原始交易数据当成源码
Bitcoin开发者参考将getrawtransaction定义为获取原始交易数据的接口，其结果可包含序列化的十六进制数据或交易信息对象。“原始”描述的是交易数据形式，不代表开发者编写的源文件。查询到交易输入、输出或脚本信息，也不等于取得了完整应用代码。
误区六：查不到，就断定记录不存在
按照该接口文档，查询能力与交易是否在内存池、是否启用交易索引，以及是否指定可用的所在区块有关。因此，查询失败需要结合节点条件解释，不能直接推出交易不存在。
常见疑问是：拿到一份返回结果，能否结束核查？关键在于它是否回答了原问题。源码查询需要明确代码与部署对象的关系，交易查询需要明确记录与查询条件的关系；先识别证据能证明什么，再判断结论是否超出了它的范围。