哈希算出的是摘要，不是压缩包
哈希函数接收一段数据，按指定算法计算一个摘要。以SHA-256为例，无论输入是短文本还是较大的文件，输出都是256位。显示成十六进制时通常是64个字符，但这些字符并不包含一份能够直接解压还原的原文件。
因此，“数据指纹”是帮助理解的比喻，不是绝对唯一的数学保证。输入可能性很多而摘要长度固定，碰撞理论上存在；密码学哈希追求的是让寻找碰撞在计算上不可行。
同一算法还必须配合同一份字节
在相同算法下，完全相同的输入字节应得到相同结果。肉眼相似的两段文字却未必是同样的数据：末尾多了换行、空格不同，或使用不同字符编码，都可能改变摘要。计算前要先说明比较的究竟是文件、文本，还是某段序列化后的交易数据。
这也是为什么不能把两个长度相同的摘要直接混用。核验时要确认算法名称、输入范围和输出编码，不能只看它们都像一串数字字母。
区块链用哈希建立记录之间的关联
比特币区块头包含前一区块头的哈希，区块内的交易又通过默克尔树形成摘要。若修改历史交易，相应摘要和后续关联都会受影响。这里真正有意义的是数据之间可核验的关系，而不是把资料写进某个页面就自动获得保护。
哈希关系也不独自决定哪条历史有效。节点仍要验证交易和区块，共识规则还要处理竞争记录；不能把区块链的全部安全性简化成“用了哈希，所以无法改动”。
哈希、加密与签名解决的问题不同
加密通常要让持有相应密钥的人能够解密；普通哈希没有一把用于还原原文的解密钥匙。数字签名则涉及密钥，用于核验某份数据是否得到相应签名者授权。三者可以在同一系统里配合，但不应互相替代。
例如，只拿到文件和它的摘要，并不能知道文件是谁发布的。若文件与对照摘要都来自同一个不可信页面，攻击者可能把两者一起替换，比较结果一致也不能证明来源可靠。
阅读资料时先问四个核验问题
看到“已经哈希上链”的说法，可以先问：使用什么算法、实际计算了哪些数据、对照值从哪里取得、链上记录能证明到哪一步。哈希可以帮助发现字节变化，却不会自动判断内容是否真实、签约人是否有权签约，或某项商业承诺是否能够兑现。把技术证据的范围说清楚，比只展示一长串摘要更有用。