os.ReadFile + md5.Sum 并发更慢是因为 os.ReadFile 一次性加载大文件致内存暴涨、GC 压力剧增，且磁盘 I/O 本质串行争抢；应改用 os.Open + io.Copy 流式计算，每个 goroutine 独立打开文件、创建哈希实例，并用 semaphore 控制并发数。
为什么 os.ReadFile + md5.Sum 并发反而更慢
因为 os.ReadFile 会把整个文件一次性加载进内存，1GB 文件就占 1GB 内存；协程越多，GC 压力越大，内存分配暴增，而底层磁盘 I/O 仍是串行争抢。实测几十 MB 以上文件时，并发数超过 CPU 核心数后吞吐不升反降。
每个 goroutine 必须独立 os.Open + io.Copy
流式计算是唯一安全路径，不能共享句柄或哈希实例：
-
os.Open打开文件，紧跟defer f.Close()，确保句柄及时释放 - 每个 goroutine 调用一次
sha256.New()（或md5.New()），hash.Hash不是并发安全的，复用会导致结果串接错误 - 直接
io.Copy(hasher, f)，它内部默认用 32KB 缓冲区，且对hash.Hash尝试零拷贝路径，比手动分块更稳更快 - 务必检查
io.Copy的error返回值——磁盘拔掉、权限变更、NFS 挂掉都会在这里暴露，否则部分读取失败却无提示 - 结果用
hasher.Sum(nil)获取，别用hasher.Sum([]byte{})（后者多一次切片分配）
并发数不是越多越好，得看 IO 类型
盲目起 100 个 goroutine 很容易翻车：
- 本地 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 次重试（每次time.Sleep(100 * time.Millisecond)） - 校验前必须确保完整读完——这不是哈希问题，而是读取中断；
io.Copy返回的n和err都要检查，n == 0 && err == nil是空文件，err != nil表示读取异常，此时哈希值无效
真正难的不是起多少 goroutine，而是判断“这次校验到底要解决什么问题”：防传输损坏？防恶意篡改？还是仅做快速一致性快筛？目标不同，并发策略、算法选择、错误容忍度全都不一样。
