并发用 os.ReadFile + md5.Sum 更慢，因其一次性加载全文件致内存暴涨、GC 压力大，磁盘 I/O 仍串行争抢；正确做法是每个 goroutine 独立 os.Open + io.Copy 流式计算，配合适当并发数与错误处理。
为什么并发用 os.ReadFile + md5.Sum 反而更慢
因为 os.ReadFile 会把整个文件一次性加载进内存，1GB 文件就占 1GB 内存；协程越多，GC 压力越大，内存分配暴增，而底层磁盘 I/O 仍是串行争抢。实测几十 MB 以上文件时，并发数超过 CPU 核心数后吞吐不升反降。
正确做法：每个 goroutine 独占 os.Open + io.Copy 流式计算
每个文件必须独立打开、独立哈希实例、独立读取流：
- 用
os.Open打开文件，defer f.Close()确保句柄释放 - 每个 goroutine 调用一次
md5.New()，hash.Hash不是并发安全的，不能复用 - 直接
io.Copy(h, f)，它内部默认用 32KB 缓冲区，且对hash.Hash尝试零拷贝路径，比手动分块更稳更快 - 务必检查
io.Copy的 error 返回值，否则部分读取失败会导致 MD5 错误但无提示 - 结果用
h.Sum(nil)获取，别用h.Sum([]byte{})（后者多一次切片分配）
并发数怎么设才不翻车
不是越多越好，取决于 IO 类型和系统负载：
- 本地 SSD：可设为
runtime.NumCPU() * 2 - NFS 或机械硬盘：4–8 个协程往往就是极限
- 用
golang.org/x/sync/semaphore控制并发，比无脑起 goroutine 更可靠 - 文件按大小分组处理：小文件走高并发，大文件（如 >2GB）单独限 1–2 协程
- 监控
runtime.ReadMemStats的Alloc和NumGC，GC 频次突增说明并发已超内存承受力
容易被忽略的坑：Windows 文件句柄冲突与校验完整性
Windows 下常报 The process cannot access the file because it is being used by another process，根源是资源管理器预览、杀毒软件扫描等进程已持有该文件句柄：
立即学习“go语言免费学习笔记（深入）”；
- 改用
os.OpenFile(path, os.O_RDONLY|os.O_CLOEXEC, 0)，显式加os.O_CLOEXEC - 捕获
os.IsPermission和特定错误字符串，加最多 3 次重试（每次 sleep 100ms） - 校验前必须确保
io.Copy完整读完，否则h.Sum(nil)结果不完整——这不是哈希问题，而是读取中断 - MD5 本身只适合防意外损坏（传输丢包、磁盘坏道），不防恶意篡改；对外分发或签名场景请换
sha256.New()
