为什么 filepath.Walk 比 os.ReadDir + 手动递归慢一倍？
因为 filepath.Walk 默认对每个文件调用 os.Stat，哪怕你只关心路径名。它会为每个条目触发一次系统调用，而 os.ReadDir（Go 1.16+）返回的 fs.DirEntry 已经包含类型和名称，IsDir() 不触发额外 stat。
- 优先用
os.ReadDir替代filepath.ReadDir（后者已弃用） - 递归时只对确认是目录的条目再调用
os.ReadDir，跳过os.Stat - 避免在遍历循环里做 I/O、字符串拼接或正则匹配——这些会放大延迟
如何避免 filepath.Walk 的隐式 os.Stat 开销？
如果你必须用 filepath.Walk（比如要兼容旧版 Go），可以通过 filepath.WalkDir（Go 1.16+）替代，并传入自定义 fs.WalkDirFunc，它接收的是 fs.DirEntry，不是 os.FileInfo。
-
filepath.WalkDir的回调函数签名是func(path string, d fs.DirEntry, err error) error -
d.IsDir()安全、零开销；只有真需要大小/修改时间时才调用d.Info() - 若
err != nil且是fs.SkipDir，可跳过该子树，减少无效遍历
并发遍历目录真的更快吗？什么情况下反而更慢？
并发读目录本身不加速，甚至因 goroutine 调度和 OS 文件句柄竞争而变慢；但如果你后续要对每个文件做 CPU 密集处理（如哈希、解析），才值得把“读路径”和“处理内容”拆开。
- 纯遍历（只收集路径）：单协程 +
os.ReadDir最快 - 混合任务（如扫描并计算 SHA256）：用 worker pool，生产者用单协程递归读路径，消费者并发处理
- 注意
os.File句柄数限制，默认可能被耗尽，需设runtime.GOMAXPROCS和控制并发数（如 4–8）
Windows 下路径拼接慢？别用 path.Join 做热路径
path.Join 是安全但较重的通用方案，内部有大量字符串切分和判断。在每层递归都拼路径时，它会成为瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 改用
filepath.Join—— 它针对各平台做了优化，Windows 下直接用\分隔符逻辑 - 更激进的做法：用
strings.Builder缓存父路径，追加/和子名（注意跨平台分隔符统一为/或用filepath.Separator） - 绝对路径遍历时，避免反复解析根路径；提前转成
filepath.Clean后复用
os.Stat、一层无意义的 path.Join、或者 Windows 上没关掉 8.3 短文件名生成。测速前先用 go tool trace 看 goroutine 阻塞点，比猜更快。 
