go中sha256.new()不可在goroutine间共享，必须每个goroutine独占实例以避免竞态；大文件不可拆分并行哈希，小文件批量校验宜控制并发数并复用实例（需reset或sync.pool），瓶颈常在于io而非cpu。
Go 里用 crypto/sha256 做并行哈希，不是简单起个 goroutine 就完事——不控制并发、不复用实例、不区分数据粒度，反而比串行还慢，甚至触发 OOM 或竞争 panic。
sha256.New() 能否在 goroutine 间共享？
不能。每个 goroutine 必须用自己的 sha256.Hash 实例。共享会导致 Write() 和 Sum() 竞态，结果不可预测，且 Go 的 hash.Hash 接口明确不保证并发安全。
- 正确做法：每个 worker 分配独立
h := sha256.New() - 错误写法：
var h = sha256.New(); go func() { h.Write(data) }()—— 多个 goroutine 同时调Write会破坏内部状态 - 若需复用（如批量小文件），用
sync.Pool缓存sha256.Hash，但必须确保出池后调用Reset()，否则残留旧状态
大数据块并行 vs 小文件并行，策略完全不同
并行收益取决于任务是否真正独立、IO 是否瓶颈、以及哈希器初始化开销占比。
- 处理 1000 个 1MB 文件：适合并行，每个文件一个 goroutine + 独立
sha256.New()，并发数控制在runtime.NumCPU()附近即可 - 单个 2GB 文件：不能拆成多 goroutine 并行喂给同一个哈希器——SHA256 是顺序累积状态，强行分块并行会得到错误结果；只能用单 goroutine +
io.Copy流式处理 - 若要提速大文件，靠的是 OS 层预读、SSD 随机读优化，或加
bufio.NewReader减少系统调用次数，而非 goroutine
为什么 fmt.Sprintf("%x", h.Sum(nil)) 比 hex.EncodeToString 更快？
因为前者直接格式化字节切片，不依赖额外包，也不做内存拷贝；后者需导入 encoding/hex，且内部有额外的 slice 操作和分配。
- 推荐写法：
fmt.Sprintf("%x", h.Sum(nil))—— 简洁、零依赖、性能略优 - 禁用写法：
hex.EncodeToString(h.Sum(nil)[:])——h.Sum(nil)已是[]byte，[:]冗余，编译器无法优化掉 - 注意：
fmt.Sprintf输出小写十六进制，与shasum -a 256一致，无需额外strings.ToLower
复用 hash 实例时 Reset() 的坑
Reset() 清空状态但不重置底层缓冲区长度，多次调用后若输入长度波动大，可能引发意外内存增长或 GC 压力。
- 安全复用场景：所有待哈希数据长度相近（如固定结构的 protobuf 消息）
- 危险场景：先哈希 1KB 字符串，再哈希 10MB 文件——第二次
Write可能触发底层 buffer 扩容，且扩容后的内存不会自动缩回 - 更稳做法：对长度差异大的任务，不用
Reset()，直接新建实例；对高频小数据，用sync.Pool管理，Pool 的New函数里返回新sha256.New()
最易被忽略的一点：并行哈希的瓶颈往往不在 CPU，而在文件打开速度、磁盘 IO 或系统 open file limit。没加 defer f.Close() 或没限制并发数，跑几小时就卡在 too many open files，比算法慢更致命。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
