并发使用 os.readfile + md5.sum 反而变慢，因一次性加载全文件致内存与gc压力剧增，且底层io仍串行；应改用 os.open + io.copy 流式读取，配合文件大小预检、独占文件句柄及 sync.pool 缓存 hash.hash。
为什么 os.ReadFile + md5.Sum 并发反而变慢？
因为默认用 os.ReadFile 会一次性把整个文件读进内存，协程越多，内存分配和 GC 压力越大，IO 还是串行在底层磁盘上抢队列。尤其处理几十 MB 以上的文件时，协程数 > CPU 核心数后，吞吐不升反降。
- 改用
os.Open配合io.Copy流式读取，避免内存爆炸 - 每个协程独占一个
*os.File句柄，不要复用或共享文件对象（否则会竞态） - 提前用
os.Stat检查文件大小，跳过空文件或超大文件（比如 >2GB）直接报错或走降级逻辑
sync.Pool 缓存 hash.Hash 实例真有用吗？
有用，但只对高频小文件（
- 必须用
pool.Get().(hash.Hash)强制类型断言，且每次用完立刻Reset()，不能只Sum(nil) - 别把
md5.New()直接塞进 Pool —— 它返回的是接口，底层结构体字段未归零，会导致后续哈希值错误 - 更安全的做法：Pool 存的是自定义结构体，内嵌
hash.Hash并封装Reset和Sum方法
并发数设多少才不翻车？
不是越多越好，关键看 IO 类型和系统负载。本地 SSD 可设 runtime.NumCPU() * 2，但网络文件系统（如 NFS）或机械硬盘上，4–8 个协程往往就是极限。
- 用
semaphore（比如golang.org/x/sync/semaphore）控并发，比无脑起 goroutine 更稳 - 文件路径列表按大小分组：小文件走高并发，大文件单独串行或限 1–2 协程
- 监控
runtime.ReadMemStats的Alloc和NumGC，如果 GC 频次突增，说明协程数已超内存承受力
Windows 下打开文件失败报 The process cannot access the file because it is being used by another process 怎么办？
这是 Windows 文件句柄独占策略导致的，即使你用 os.O_RDONLY 打开，其他进程只要以任何方式持有该文件（包括资源管理器预览、杀毒软件扫描），就可能失败。
立即学习“go语言免费学习笔记（深入）”；
- 加重试逻辑：捕获
os.IsPermission和特定错误字符串，sleep 100ms 后重试，最多 3 次 - 优先用
os.OpenFile(path, os.O_RDONLY|os.O_CLOEXEC, 0)，显式加os.O_CLOEXEC防止子进程继承句柄 - 生产环境建议绕开问题文件：记录日志 + 跳过，而不是卡死或 panic
实际跑起来最麻烦的永远不是哈希算法本身，而是文件句柄生命周期、跨平台 IO 行为差异、以及内存和 GC 在高并发下的隐性反馈。这些地方没盯住，再多协程也白搭。
