正确计算区块哈希需严格按prevHash、data、timestamp、nonce顺序拼接字符串并用SHA-256计算，统一UTF-8编码，禁用toString()或hashCode()；PoW中nonce应使用long类型并设最大尝试次数；链式校验须确保prevHash准确传递且hash字段不可变。
区块哈希怎么算才对：别用 toString() 直接拼字符串
Java 里最容易错的，就是把 Block 对象直接 toString() 然后哈希——这会导致每次 JVM 实例不同、字段顺序不固定、调试信息混入，哈希值完全不可重现。
正确做法是严格按字段顺序序列化关键数据（不含哈希本身），再用标准算法计算：
- 只参与哈希的字段：前一区块哈希
prevHash、当前交易数据data、时间戳timestamp、随机数nonce - 必须统一编码：用
StandardCharsets.UTF_8，别依赖平台默认编码 - 推荐用
MessageDigest.getInstance("SHA-256")，别用已废弃的java.security.DigestUtils（Apache Commons）或自定义 MD5
示例关键片段：
String input = prevHash + data + timestamp + nonce;
byte[] hashBytes = MessageDigest.getInstance("SHA-256")
.digest(input.getBytes(StandardCharsets.UTF_8));
工作量证明（PoW）的 while 循环卡死？检查 nonce 溢出和终止条件
Java 的 int 是 32 位有符号数，暴力递增 nonce 到 Integer.MAX_VALUE 后会变负，导致永远凑不出前导零哈希——这不是算力不够，是整数翻转了。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 用
long类型存nonce，避免溢出（虽然实际中前导零要求不高，但代码得健壮） - 必须设最大尝试次数，比如
MAX_NONCE = 10_000_000L，否则测试时可能卡住几秒甚至更久 - 难度用「前导零个数」表示，校验时别用正则，用
hashHex.startsWith("000")更快；注意hashBytes要转成小写十六进制字符串（String.format("%064x", ...)或DatatypeConverter.printHexBinary(...).toLowerCase()）
链式校验失败？重点查 prevHash 字段是否被意外修改
新建区块时，如果忘了把上一个区块的 hash 赋给新块的 prevHash，或者用了引用拷贝（比如直接 newBlock.prevHash = lastBlock.hash 但 lastBlock.hash 后续又被重算），整个链就断了——校验时发现 computeHash() != storedPrevHash，但错误提示往往只说「invalid chain」，不指明哪一环。
排查要点：
- 每个新区块创建后，立即调用
calculateHash()并赋值给自己的hash字段，再把该值传给下一个区块的prevHash - 校验整条链时，从第二个区块开始，逐个比对
block.prevHash.equals(block.previous.calculateHash())，不要跳过索引 0 - 避免在
Block类里把hash设为可变字段（如 public 修饰或提供 setter），否则外部误改会破坏一致性
为什么用 SHA-256 而不是 Java 自带的 hashCode()？
hashCode() 是 JVM 运行时生成的、不跨进程/重启一致、也不具备密码学抗碰撞性——两个不同内容的区块很可能算出相同 hashCode()，链式校验瞬间失效。
真实场景中必须用密码学哈希：
-
hashCode()只适合内存内临时哈希表，不能用于持久化或共识 - 区块链要求「确定性 + 不可逆 + 抗碰撞」，只有
SHA-256、SHA-3这类满足 - 别为了省事用
Objects.hash(prevHash, data, timestamp, nonce)，它底层还是调hashCode()，结果不可靠
真正难的不是写 PoW 循环，而是让每个区块的输入数据完全可控、不可变、可复现——少一个 final 修饰符，多一次手抖的 setter 调用，链就不是链了。
