sha512.Sum512 和 []byte 之间怎么安全转换
直接把 sha512.Sum512 当作 []byte 用会出问题——它本质是带固定长度的结构体，不是切片。常见错误是写 sum[:] 却没注意底层数组是否被意外修改，或者误以为 sum[:] 总是返回 64 字节（其实它确实总是 64 字节，但语义上不等于可变切片）。
正确做法是显式转成不可变字节序列：
- 需要只读哈希值：用
sum.Sum(nil)，返回[]byte，内容复制、安全、长度恒为 64 - 需要高性能且确定不改写：用
sum[:]，但必须确保sum本身不会被后续Sum512.Write()调用覆盖（比如你是在Sum512计算完成后才取值） - 别用
unsafe.Slice(unsafe.Pointer(&sum), 64)—— Go 1.21+ 虽支持，但破坏内存安全边界，校验逻辑一旦嵌入关键链路（如签名比对），可能引发静默失败
为什么 crypto/sha512.New() 比 sha512.Sum512{} 更适合流式校验
当你处理大文件或网络流时，sha512.Sum512{} 只能一次性塞入全部数据；而 crypto/sha512.New() 返回的是 hash.Hash 接口，支持分块 Write() + 最终 Sum(nil)，这才是真正实用的数据一致性校验路径。
典型坑点：
立即学习“go语言免费学习笔记（深入）”；
- 用
Sum512{}做增量更新？不行——它没实现hash.Hash，不能Write() - 重复调用
sha512.New()然后Sum(nil)却没Reset()？会导致哈希值叠加，结果错乱 - 并发写同一个
hash.Hash实例？crypto/sha512不保证并发安全，必须加锁或每个 goroutine 独占一个实例
校验失败却没报错？检查 Sum512.Sum(nil) 的字节顺序和比较方式
SHA-512 输出是 64 字节原始二进制，不是 hex 或 base64。常见错误是：把期望值存成 "e7f8..." 这样的 hex 字符串，却用 bytes.Equal(hash.Sum(nil), []byte("e7f8...")) 直接比——这永远失败，因为一边是二进制，一边是 ASCII 字符。
正确做法取决于你的输入源：
- 期望值来自 hex 字符串：用
hex.DecodeString("e7f8...")先解码成[]byte，再比 - 期望值来自其他 Go 程序传来的
sha512.Sum512：直接比sum1 == sum2（结构体可比较） - 做常量时间比较防侧信道攻击（如 token 校验）：用
subtle.ConstantTimeCompare()，别用bytes.Equal()
SHA-512 在 Go 中的性能陷阱：别在循环里反复 New()
sha512.New() 内部会分配哈希上下文结构并初始化状态，开销虽小但可累积。如果你在高频循环中（比如每条日志、每个 RPC 请求）都调用它，GC 压力和 CPU 时间会明显上升。
更优解：
- 复用实例：用
sync.Pool缓存hash.Hash实例，Get()后Reset()，用完Put() - 确认是否真需要 SHA-512：SHA-256 在大多数校验场景已足够，SHA-512 计算耗时约高 20–30%，且输出体积翻倍，增加存储/传输负担
- 纯校验（非密码学签名）场景，考虑
xxhash或fnv：快 5–10 倍，但注意它们不抗碰撞性，仅限可信环境内部一致性检查
哈希值本身是确定性的，但怎么生成、怎么比、怎么复用，每一步漏掉细节，校验就只是个心理安慰。
