大文本并发哈希需切片分发至独立worker，每worker新建hash.hash实例流式处理，避免md5.sum内存爆炸与并发错误；流水线须控缓冲、设合理goroutine数。
大文本字符串并发哈希计算不能靠简单起 Goroutine 就完事——io.Copy 用不上，md5.Sum/sha256.Sum 会内存爆炸，而直接在 goroutine 里反复 hash.Write 又容易因共享状态出错。核心解法是：把字符串切片 → 分发到 worker → 每个 worker 独立建 hash.Hash 实例 → 收集结果。流水线不是噱头，是避免缓冲区堆积和 goroutine 泄露的刚需。
为什么不能直接对 []byte 调用 Sum 类型
md5.Sum 和 sha256.Sum 内部把整个输入缓存在结构体字段里，比如 md5.Sum 是 [md5.Size]byte（16 字节），但它的 Sum([]byte) 方法只接受小数据；一旦你传入几 MB 的 []byte，它会复制整块内存进栈或堆，且无法流式处理。更危险的是，并发调用 md5.Sum(data) 看似无状态，实则每个调用都隐式分配新数组，GC 压力陡增。
- 错误写法：
md5.Sum([]byte(largeString))—— 大字符串直接进内存，OOM 风险高 - 正确路径：必须走
hash.Hash接口，用h := md5.New()+h.Write([]byte(s))+h.Sum(nil) - 注意：
h.Sum(nil)返回新切片，h.Sum(dst)是追加模式，别混用
worker 模型中 hash 实例必须 per-goroutine 创建
同一个 hash.Hash 实例不可并发调用 Write —— 它不是线程安全的。哪怕你用 sync.Mutex 包一层，也会让流水线退化成串行。所以每个 goroutine 必须自己调用 md5.New() 或 sha256.New()，各自维护独立状态。
- 别复用 hasher：哪怕加了
Reset()，也得确保无并发写入，否则结果错乱 - 字符串长度差异大时，建议按字节数（非 rune 数）切分，避免 UTF-8 截断：用
[]byte(s)直接切，不走utf8.DecodeRune - worker 输入推荐用
chan string或chan []byte，前者更安全（避免意外修改原 slice）
流水线 stage 划分与 channel 缓冲控制
典型三段式：producer → hasher → collector。关键不是“快”，而是防止 producer 把 channel 塞爆、或 collector 拖慢整个链路。缓冲区大小必须显式设，且不宜过大。
-
jobs := make(chan string, 100)—— 缓冲 100 条任务，够多数场景，再大易占内存 - worker 数量建议设为
runtime.NumCPU()，超配反而增加调度开销 - collector 侧用
for i := 0; i 等待，或更稳妥地用 <code>sync.WaitGroup+close()配合 - 别忘了 recover：worker 内 panic 会 kill goroutine，需包
defer func(){...}()捕获
SHA256 与 MD5 在并发流水线里的实际差异
算法本身不影响并发模型，但影响资源占用和校验语义。SHA256 输出 32 字节，MD5 是 16 字节，内存带宽消耗略高；更重要的是，Go 标准库中 sha256.New() 内部缓冲区默认比 md5.New() 大（约 32KB vs 8KB），意味着单次 Write 吞吐更高，但初始化稍重。
- 若业务只要校验一致性（如去重），MD5 足够，且生成更快
- 若涉及外部系统交互（如 API 签名、区块链存证），必须用 SHA256，且注意 hex 编码全小写，和
shasum -a 256一致 - 所有 hasher 结果统一用
hex.EncodeToString(h.Sum(nil))，别用fmt.Sprintf("%x", ...)—— 后者对非字节切片行为未定义
最易被忽略的点：字符串来源是否含 BOM、CRLF、尾随空格或零宽字符。这些在哈希前不会自动 trim，且不同系统读取方式不同。流水线里最好在 producer 阶段就做一次标准化（如 strings.TrimSpace + bytes.TrimRight([]byte(s), "\r\n\t ")），否则并发算出来的哈希值看似一致，实则因输入隐形差异而失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
