为什么HashAlgorithm.ComputeHash对相同数据返回不同的哈希值？

你的哈希校验失败核心原因就是提交时参与哈希计算的原始数据，和从数据库读取后的数据存在差异，具体常见的触发点如下：

• DateTime精度丢失
  你代码中用DateTime.Now赋值时间戳，C#的DateTime精度为100纳秒级，但绝大多数数据库的datetime/datetime2类型存储精度最高只有毫秒级，数据写入数据库时会自动截断尾部的滴答数，读取后的值和原始值已经不一致，序列化后生成的字节数组自然不同，最终哈希结果不匹配。
• JSON序列化行为不稳定
  你用System.Text.Json序列化对象计算哈希，还开启了ReferenceHandler.Preserve配置，这个配置会在序列化结果中加入$id、$ref等引用标记：如果从数据库读取后，对象的引用关系和提交时不一致（比如原本同一个引用的对象读出来变成两个独立实例），序列化结果会直接变化。另外如果序列化配置没有固定属性排序、忽略规则，两次序列化的输出也可能存在差异。
• 字节数组存储/读取不一致
  代码中涉及PrevHash、Hash等byte[]类型的字段，这类字段存入数据库时通常会转成Base64/十六进制字符串存储，如果读写过程中转码逻辑不一致（比如十六进制大小写不统一、字节顺序错误、截断多余字节），读取后的值和原始值就会存在差异。比如你创世块的PrevHash = BitConverter.GetBytes('0')，这里的'0'是char类型，在C#里占2个字节，如果数据库字段长度不够，存储时就会被截断。
• ORM框架自动修改属性值
  如果用EF Core等ORM框架存取数据，ORM可能会自动补全导航属性、默认值属性等字段，如果这些字段被包含在DataToHash的序列化范围内，也会导致两次计算的输入数据不一致。

• 统一时间戳精度：将时间戳提前转为固定精度的Unix时间戳（毫秒/秒级）再存储，或者用DateTimeOffset类型避免时区、精度问题。
• 固定哈希输入逻辑：不要依赖JSON序列化的默认行为，将所有需要参与哈希计算的字段按固定顺序拼接成明文字符串，再编码为UTF8字节数组计算哈希，彻底避免序列化的不确定性。
• 对比序列化输出排查问题：调试阶段可以分别打印提交时、读取后DataToHash序列化后的完整JSON字符串，直接对比差异就能快速定位不一致的字段。
• 统一字节数组存取逻辑：byte[]类型存数据库时统一用Base64字符串格式，读写时用同一套转码逻辑，避免转码错误。

内容的提问来源于stack exchange，提问作者Kamil