hash.Hash 接口到底要实现哪些方法
必须实现 Write、Sum、Reset、Size、BlockSize 这五个方法，缺一不可——Go 标准库里所有哈希计算（比如 hash/crc32、crypto/sha256）都靠这个接口统一调用，不是只写 Write 就能塞进 io.Copy 或 hash.Hash 参数位置的。
常见错误是漏掉 BlockSize 返回 0，导致后续用 hash.Hash 做流式加盐（比如配合 crypto/hmac）时 panic；或者 Sum 没做拷贝，返回内部切片，外部修改会污染下一次 Reset 后的状态。
-
Write(p []byte) (n int, err error)：必须按字节流语义追加，不能截断或重排 -
Sum([]byte)：应 append 到传入切片后返回新切片，别直接返回内部缓冲区 -
BlockSize()：哪怕不用于分块（如纯累积哈希），也得返回合理值（比如 1 或典型输入块大小），否则hash/maphash等依赖它的包会出错
为什么自定义哈希不能直接嵌入 crypto.Hash
crypto.Hash 是一个枚举类型，只用于标识标准算法（crypto.SHA256、crypto.MD5 等），它和 hash.Hash 接口完全无关。试图让自定义类型实现 crypto.Hash 会导致编译失败——它根本不是接口，只是 uint 别名。
真正需要对接的是 hash.Hash，而如果你希望在 crypto/hmac.New 这类函数里复用，还得额外确保你的类型满足其隐含要求：支持 Blocksize() > 0、Sum 可多次调用、Reset 后状态干净。
立即学习“go语言免费学习笔记（深入）”；
- 误以为实现
crypto.Hash就能被hmac.New接受 → 实际会报cannot use myHash as crypto.Hash - 想用
hmac.New包装自定义哈希 → 必须先确认你的BlockSize()返回值 ≥ 1，且内部缓冲区在Reset()后清空 - 标准库中只有
crypto/*下的哈希才注册到crypto.Hash枚举，自定义的永远不在其中
Write 方法里对 []byte 的处理陷阱
很多人在 Write 里直接拿 p 做缓存或哈希输入，结果遇到数据被上层复用（比如 bytes.Buffer.Write 复用底层数组）时，哈希值突然错乱——因为 p 只是临时切片，生命周期不由你控制。
正确做法是立刻拷贝或逐字节处理，尤其当你的哈希逻辑涉及状态机、滑动窗口或异步更新时，更不能持有原始 p 引用。
- 错误示例：
h.buf = p // 危险！p 可能被复用 - 安全做法：用
copy(h.internalBuf[len(h.internalBuf):], p)或逐字节喂给核心算法 - 如果哈希算法本身支持增量更新（比如 xxHash 的
Write），优先走原生路径；别为了“省一次拷贝”绕过内存安全边界
测试自定义 hash.Hash 是否真兼容标准流程
光跑通单次 Write+Sum 不代表可用。真正容易翻车的场景是流式读取、重复 Reset、和标准库组合使用。最简验证方式是套进三个典型上下文：
- 用
io.Copy(myHash, strings.NewReader("hello"))→ 检查是否 panic 或返回错误长度 - 连续调用
Write→Sum→Reset→Write→Sum，两次结果必须一致 - 传给
hmac.New(myHash, key)（前提是BlockSize() > 0），再写入数据，看输出是否稳定
特别注意 Sum(nil) 和 Sum([]byte{}) 行为是否一致，有些实现对 nil 切片做特殊分配，但标准库某些地方（比如 archive/zip 计算校验和）会传空切片进来。
