区块链必须用sha256而非md5或sha1，因其抗碰撞性已被攻破；block需显式存hash字段以保障链式验证锚点；禁用json序列化哈希，须用确定性字节拼接；所有输入须严格可控、不可变、可复现。
为什么用 sha256 而不是 md5 或 sha1
区块链的链式结构依赖哈希的抗碰撞性和单向性，md5 和 sha1 已被证实存在实际碰撞攻击，Golang 标准库虽仍保留它们，但用于区块哈希会直接削弱安全性基础。生产环境不用，原型阶段也不该养成习惯。
实操建议：
• 始终用 crypto/sha256 包，调用 sha256.Sum256() 得到固定 32 字节哈希值
• 不要自己拼接字符串再哈希（如 "prev_hash" + "data"），容易因边界模糊导致相同内容生成不同哈希——改用结构体序列化或明确分隔符
• 注意：sha256.Sum256() 返回的是值类型，取哈希要用 .[:] 转为 []byte，否则直接传结构体会隐式复制，后续比较失败
Block 结构体里为什么必须包含 Hash 字段而非运行时计算
区块哈希不是元数据，而是链式验证的核心锚点。每个新区块必须包含前一个区块的完整哈希值（即 PrevHash），而自身哈希又必须覆盖 PrevHash、Data、Timestamp 等全部关键字段——如果 Hash 不作为字段显式存储，每次验证都要重新计算，既低效又无法保证“该哈希确实由当时字段生成”。
实操建议：
• Block 定义中必须有 Hash []byte 字段，且在创建后立即计算并赋值
• 计算哈希前先确保 PrevHash 已设置（创世块用全 0 或空切片）
• 避免在 Hash 字段上做指针操作或浅拷贝，Go 中切片是引用头，block1.Hash = block2.Hash 后修改任一会影响另一
• 示例：创建区块后立刻调用 block.SetHash() 方法，内部用 sha256.Sum256(fmt.Sprintf("%x%v%d", block.PrevHash, block.Data, block.Timestamp)) ——注意这里用 %x 输出十六进制避免字节乱序
验证链条断裂时最常见的三个错误现象
跑起来看似连贯，但一加新区块就验证失败，通常不是算法错，而是状态没对齐。
常见错误现象：
• invalid prev_hash in block #5：第 5 块的 PrevHash 和第 4 块实际计算出的 Hash 不一致，大概率是第 4 块创建后又被意外修改过字段，但没重算哈希
• 新区块总能加进去，但 IsValid() 返回 false：验证逻辑里漏了检查 PrevHash 是否为空（创世块除外），或误用 == 比较切片（应使用 bytes.Equal）
• 链长度显示 10，但遍历打印哈希时从第 7 块开始全是空：结构体初始化用了 var b Block 而非 Block{}，导致 Hash 是 nil 切片，后续 append 或 copy 出错
实操建议：
• 每次修改 Block 任何字段后，必须显式调用哈希重算方法
• 验证函数开头加断言：if len(b.PrevHash) == 0 && index != 0 { return false }
• 打印调试时统一用 fmt.Printf("%x", b.Hash)，别用 %v，避免把 nil 切片和空切片混为一谈
为什么不用 json.Marshal 直接哈希整个结构体
看起来最省事，但 JSON 序列化会受字段顺序、空字段处理、浮点数精度、时间格式等影响，同一结构体在不同 Go 版本或不同 json.Marshal 调用下可能产出不同字符串——这会让哈希失去确定性，彻底破坏链式验证前提。
实操建议：
• 绝对不要对结构体直接 json.Marshal 后哈希
• 如果必须序列化，手写确定性编码：按字段声明顺序，用 binary.Write 写入定长字段，变长字段前置长度（如 uint32(len(data)) + data）
• 更简单稳妥的做法：只哈希关键字段组合，例如 sha256(append(append(prev[:], data...), timestampBytes...))，确保所有输入都是原始字节且顺序固定
• 注意：time.Now().UnixNano() 返回 int64，转字节数组必须用 binary.LittleEndian.PutUint64(buf, ts)，不能用 strconv.AppendInt，后者产生字符串，长度不固定
立即学习“go语言免费学习笔记（深入）”；
哈希链真正的复杂点不在计算本身，而在所有参与哈希的输入是否严格可控、不可变、可复现——哪怕时间戳多纳秒级误差，或字节切片少一次copy，整条链的验证就会无声崩塌。 
