误区一：把所有链上查询都当成源码查询
“区块链源码”容易混指节点软件源码、智能合约源码和链上交易数据。三者对应不同问题：软件怎样实现、合约怎样执行，以及某笔交易记录了什么。查询前应先明确对象，否则即使取得真实数据，也可能没有回答原本的问题。
以太坊开发者文档讨论的是智能合约源码验证；Bitcoin 开发者参考中的 getrawtransaction 则用于获取原始交易数据。两者不能互相替代，交易的十六进制表示也不能直接当作高级语言源码。
误区二：看到公开源码，就认为它与部署代码一致
源码公开解决了“能否阅读”的问题，源码验证进一步检查它与部署代码的对应关系。按照以太坊文档的解释，验证需要结合源文件和编译设置重新编译，再比较相关字节码。
因此，单独看到一份代码并不足以确认对应关系。编译器版本、优化设置等条件也属于验证依据。阅读时应区分“项目展示了什么代码”和“验证结果证明了什么对应关系”。
误区三：验证通过，就代表没有漏洞
源码验证主要回答代码是否对应，形式化验证则在所定义的要求下讨论行为是否符合预期。前者不能直接证明业务逻辑正确，也不能自动排除危险权限或漏洞。
验证标签的含义应限定在它实际检查的范围内。代码可供检查与代码已经得到充分安全评估，是两个需要分别举证的结论。
误区四：所有匹配结果都具有相同含义
以太坊文档区分了部分匹配与结合元数据哈希的完整匹配。注释等内容可能不影响可执行逻辑；结合元数据核对，能够更严格地确认源文件及编译信息的一致性。
因此，理解验证结果时还要看匹配类型。注释中的功能描述仍需结合实际逻辑阅读，不能因为文字出现在已验证源码中，就把描述直接当成行为证明。
误区五：查询不到，就说明交易不存在
Bitcoin 的 getrawtransaction 参考说明，查询能力受条件限制：未指定区块哈希时，交易是否在内存池中、节点是否启用交易索引等会影响结果；指定区块哈希时，还要求相应区块可用且包含该交易。
遇到查询失败，应先辨别是目标不匹配、数据不可用，还是查询条件不足。一次接口返回失败，只能说明此次查询未取得结果，不能单凭它推断整个链上不存在该交易。