filepath.Walk性能差因默认对每个条目调用os.Stat，而os.ReadDir返回fs.DirEntry，Name()和IsDir()零系统调用，故快一倍；需手动递归、路径用filepath.Join、错误须显式处理。
别用 filepath.Walk 遍历含大量小文件的目录树——它默认对每个条目调用 os.Stat，系统调用翻倍，性能直接腰斩。
为什么 os.ReadDir + 手动递归比 filepath.Walk 快一倍？
因为 os.ReadDir 返回的是 fs.DirEntry 切片，entry.Name() 和 entry.IsDir() 都不触发额外系统调用；而 filepath.Walk 每次回调都传 os.FileInfo，背后必走一次 os.Stat。
- 只列当前层？直接用
os.ReadDir(dir)，别碰已废弃的ioutil.ReadDir - 需要递归？对每个
entry先判entry.IsDir()，仅对目录再调os.ReadDir，跳过所有非目录项的os.Stat - 路径拼接别写
dir + "/" + name：Windows 下失效，必须用filepath.Join(dir, entry.Name()) - 遇到
os.ErrPermission时，os.ReadDir返回非 nil error，必须显式检查，否则后续entry访问 panic
filepath.WalkDir 是不是万能替代？
它是 filepath.Walk 的轻量升级版，但不是“开箱即用”的安全方案——它不自动防护符号链接环路，也不默认忽略权限错误。
- 回调函数签名是
func(path string, d fs.DirEntry, err error) error，d.Info()才触发os.Stat，多数场景只需d.Name()和d.IsDir() - 想跳过
node_modules？在回调里写if d.IsDir() && d.Name() == "node_modules" { return filepath.SkipDir } -
err != nil时（如权限不足），必须显式return nil继续，否则遍历中断；return filepath.SkipDir对文件无效，别乱用 - 深层嵌套或 /proc/self/fd 这类路径，
WalkDir不限制深度，得自己用闭包计数器，超限就return filepath.SkipDir
并发遍历目录反而更慢？这几点先确认
纯路径收集阶段加 goroutine 几乎总是负优化——OS 文件句柄竞争、调度开销、磁盘寻道代价远高于 CPU 节省。
立即学习“go语言免费学习笔记（深入）”；
- 单协程 +
os.ReadDir递归，是路径遍历的最快 baseline - 真要并发？只在“读路径”和“处理内容”分离时才有意义：生产者单协程递归吐路径，消费者 worker pool 并发做哈希/解析
- 控制并发数，别盲目设
runtime.GOMAXPROCS(100)：4–8 个 worker 通常足够，再多易触发句柄耗尽（too many open files） - Windows 下注意关闭 8.3 短文件名生成（
fsutil behavior set disablelastaccess 1），否则每次Stat都多一次元数据查找
路径拼接和字符串操作是隐藏瓶颈
每层递归都调 path.Join？它内部做切分+判断+拼接，在百万级文件下会吃掉 15%+ CPU 时间。
- 优先用
filepath.Join替代path.Join，它针对平台做了分隔符优化 - 极端性能敏感场景：用
strings.Builder缓存父路径，追加filepath.Separator和子名（注意统一用/或filepath.Separator） - 绝对路径遍历时，提前调
filepath.Clean(root)，避免每次递归都重复解析 - 过滤后缀别用
filepath.Ext(path)：对main.go.bak返回.bak，误判；改用strings.HasSuffix(entry.Name(), ".go")
最常被忽略的点：不是算法选错，而是某次无意的 os.Stat、一层没必要的 path.Join、或者 Windows 上开着 8.3 短名——它们叠加起来，比换框架更能决定最终耗时。
