sha256+切片迭代可实现兼容以太坊/ipfs的merkle树，关键在哈希顺序、空节点补法（必须用sha256.sum256{}.[:]而非[]byte{}或make([]byte,32)）、幂次对齐三处；叶子数非2的幂时需补全零哈希，父节点拼接须严格左前右后、64字节对齐。
直接用 crypto/sha256 + 切片迭代就能实现兼容以太坊/IPFS 的 Merkle 树，不需要第三方包；关键不是“能不能写出来”，而是哈希顺序、空节点补法、幂次对齐这三处稍错就导致 root hash mismatch。
叶子数非 2 的幂时必须补 sha256.Sum256{}，不能用 []byte{}
奇数个叶子时，最后一层归并会剩一个孤立节点。协议要求它必须跟一个“空哈希”配对——这个空哈希必须是 32 字节全零，即 sha256.Sum256{} 的 [:]。常见错误：
- 用
[]byte{}或nil补：拼接时append(left[:], right[:])实际只拷贝left[:]，等效单边哈希，根哈希必然错 - 用
make([]byte, 32)：虽也是 32 字节，但未显式初始化为零，Go 中 slice 初始化不保证清零（尤其复用底层数组时） - 跳过补空、直接丢弃孤立节点：树结构坍缩，验证路径长度变短，
MerkleProof.Verify()必然失败
正确做法：计算完所有叶子哈希后，用 for len(leaves) & (len(leaves)-1) != 0 判断是否为 2 的幂，不是则循环追加 sha256.Sum256{}.[:] 直到满足。
父节点哈希必须严格左前右后拼接，且每次拼成 64 字节再哈希
每个非叶子节点的哈希，是其左右子节点哈希值（各 32 字节）拼接后再哈希的结果。顺序和字节长度都不可妥协：
- 左子哈希在前、右子哈希在后，顺序反了根哈希就不兼容 Ethereum 轻客户端
- 必须拼成严格 64 字节：用
buf := make([]byte, 64); copy(buf, left[:]); copy(buf[32:], right[:])，而不是直接append(left[:], right[:])（后者若right是 nil 切片会出问题） - 别复用同一底层数组：每次归并都要分配新
[]byte，否则上层哈希可能被下层覆盖
示例片段：
for i := 0; i left := current[i]<br> right := current[i+1]<br> buf := make([]byte, 64)<br> copy(buf, left[:])<br> copy(buf[32:], right[:])<br> h := sha256.Sum256{}<br> h = sha256.Sum256(sha256.Sum256(buf))<br> next = append(next, h)<br>}
验证时方向数组必须与构造完全一致，且长度必须等于 bits.Len(uint(len(leaves))) - 1
验证某叶子是否属于根哈希，靠的是从该叶子向上逐层拼合兄弟哈希。拼合顺序由方向数组决定，而这个数组必须和建树时每一步的左右选择完全对应：
- 方向数组长度必须是
bits.Len(uint(len(leaves))) - 1：少一个，跳过一层验证；多一个，proof[i]越界 panic - 方向标识必须明确：用
bool（true表示兄弟在右边）、或byte（0/1），不能靠“默认左倾”假设 - 拼接逻辑必须镜像建树：若建树时第 k 层对叶子 x 是
sha256.Sum256(append(left[:], right[:]))，则验证时也必须按同样顺序拼append(cur[:], sibling[:])或append(sibling[:], cur[:])
最容易被忽略的是：同一组原始数据，在不同系统中（如 Bitcoin Core vs Ethereum）对奇数叶子的补空策略不同——你得按目标链文档对齐，不是“写对就行”。
真正卡住人的从来不是哈希计算本身，而是补空逻辑是否严格匹配共识、方向是否全程一致、内存是否意外复用。这些点不盯死，哪怕代码能跑通测试向量，一接真实链就 root hash mismatch。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
