并发用os.ReadFile+md5.Sum更慢，因其一次性加载全文件致内存暴涨、GC频繁、磁盘I/O串行争抢；正确做法是每个goroutine独立os.Open+io.Copy流式计算，配合适当并发数与错误处理。
并发跑 os.ReadFile + md5.Sum 不仅不快，反而更慢——内存暴涨、GC 频繁、磁盘 I/O 串行争抢，1GB 文件可能直接 OOM。真要提速，得让每个 goroutine 独立打开文件、流式读取、独立哈希实例。
为什么 os.ReadFile 并发反而拖垮性能
它把整个文件一次性加载进内存：os.ReadFile("big.zip") 就是分配 1GB 内存；起 10 个 goroutine？就是 10GB 分配 + GC 压力爆炸。底层磁盘仍是单队列，协程再多也抢不到额外 IO 带宽。实测 >50MB 文件时，并发数超过 runtime.NumCPU() 吞吐就掉，不是线性增长，是断崖下跌。
每个 goroutine 必须独占三件套：文件句柄、哈希实例、读取流
复用任何一项都会出错：
-
os.Open每次都新调用，别传同一个*os.File进多个 goroutine（竞态） -
md5.New()必须在 goroutine 内部调用，hash.Hash不是并发安全的，也不能Reset() -
io.Copy(h, f)直接用，别手写Read+Write循环——它内部用 32KB 缓冲，还对hash.Hash做了零拷贝优化 - 必须检查
io.Copy返回的error，否则读取中断（如权限不足、磁盘坏道）不会报错，但 MD5 值已错 -
h.Sum(nil)是正确写法；h.Sum([]byte{})可能复用底层数组，在并发中互相覆盖
并发数不是越大越好，得看 IO 类型和系统反馈
盲目开 100 个 goroutine 只会让事情更糟：
立即学习“go语言免费学习笔记（深入）”；
- 本地 NVMe SSD：可设为
runtime.NumCPU() * 2 - NFS 或机械硬盘：4–8 个协程基本到顶
- 大文件（>2GB）单独限 1–2 协程，小文件再走高并发
- 用
golang.org/x/sync/semaphore控制并发，比go fn()无脑起更稳 - 监控
runtime.ReadMemStats().NumGC，GC 次数突增说明内存扛不住了
Windows 下文件打不开？不是代码问题，是句柄被占
报错 The process cannot access the file because it is being used by another process，90% 是资源管理器缩略图预览或杀毒软件在扫描：
- 改用
os.OpenFile(path, os.O_RDONLY|os.O_CLOEXEC, 0)，显式加os.O_CLOEXEC - 捕获
os.IsPermission(err)和该错误字符串，最多重试 3 次，每次time.Sleep(100 * time.Millisecond) - 校验结果前必须确认
io.Copy返回nilerror，否则哪怕只差最后一个字节没读完，MD5 就全错——这不是哈希逻辑问题，是读取不完整
真正卡点不在 MD5 算法本身（标准库已高度汇编优化），而在文件打开、内存分配、IO 调度这三层。调得再细，也绕不开 Windows 句柄独占、NFS 延迟、SSD 队列深度这些物理限制。
