filepath.WalkDir 比 Walk 快，因其默认用 io/fs.ReadDir 一次读取目录全部条目、避免逐个 os.Lstat；实测耗时仅 Walk 的 1/3～1/2，但回调中调用 os.Stat 会抵消优势。
filepath.WalkDir 为什么比 Walk 快
因为 WalkDir 默认使用 io/fs.ReadDir 接口，一次读取目录全部条目（不逐个 stat），跳过不必要的系统调用；而老版 filepath.Walk 对每个文件/子目录都调用 os.Lstat，哪怕你只关心名字。实测在含数万小文件的目录下，WalkDir 耗时通常只有 Walk 的 1/3～1/2。
但注意：快的前提是你没在回调里主动调用 os.Stat 或 os.Lstat —— 这会把性能优势直接吃掉。
遍历中提前退出的正确写法
WalkDir 的回调函数返回 error，只要不是 nil 就会终止遍历。但别直接 return errors.New("found")，Go 标准库约定用 filepath.SkipDir 跳过子树、用 io.EOF 或自定义错误（如 errFound）中断整个流程。
- 找到第一个匹配文件就停：返回自定义错误（比如
errStop），并在外层用errors.Is(err, errStop)捕获 - 跳过某个子目录（比如
.git）：在回调中对目录名判断，返回filepath.SkipDir - 不要返回
fmt.Errorf("found %s", name)这类带上下文的 error —— 容易和真实 I/O 错误混淆
匹配文件名时别忽略大小写和路径分隔符
Windows 下文件名不区分大小写，Linux/macOS 区分；而且 WalkDir 返回的 entry.Name() 是纯文件名，不含路径，entry.Inode() 在某些文件系统上不可靠。实际匹配应基于完整路径或明确归一化逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 想跨平台匹配
README.md：用strings.EqualFold(entry.Name(), "readme.md")，而不是== - 想匹配路径中包含
/vendor/的文件：用strings.Contains(filepath.ToSlash(path), "/vendor/")，避免 Windows 的\分隔符干扰 - 避免用
filepath.Base(path) == "config.json"做判断——path是传入的完整路径，entry.Name()才是当前项名，二者语义不同
并发遍历目录树反而更慢？
别用 goroutine 包裹 WalkDir 并发跑多个目录——WalkDir 本身是同步阻塞的，且磁盘 I/O 是瓶颈，加 goroutine 只会增加调度开销和系统调用竞争。真要提速，优先考虑：
- 用
filepath.Glob替代遍历（如果路径模式简单，比如**/*.go，可用golang.org/x/exp/filepath/glob实验包） - 过滤掉不需要的子目录（如
node_modules、.git）从源头减少遍历量 - 用
os.ReadDir手动递归 +sync.Pool复用[]fs.DirEntry切片（仅当 profiling 确认内存分配是瓶颈时才值得）
真正容易被忽略的是：WalkDir 不保证遍历顺序，也不承诺原子性——目录结构在遍历中途被修改（删/建/重命名），行为未定义。生产环境做文件发现类任务，得有兜底重试或快照机制。
