filepath.Walk在大目录下变慢的根本原因是默认为每个文件/目录重复调用os.Stat，导致大量系统调用、路径拼接开销及无法复用父目录FileInfo；应改用Go 1.16+的filepath.WalkDir配合fs.DirEntry优化性能。
filepath.Walk 为什么在大目录下变慢？
根本原因不是 filepath.Walk 本身逻辑复杂，而是它默认同步、串行地发起大量 stat 系统调用，并且每次递归都阻塞等待前一次 I/O 完成。当目录深度大、文件数量多（比如百万级小文件），stat 调用堆积、磁盘寻道频繁、syscall 上下文切换开销显著上升——这时 CPU 占用可能不高，但 wall-clock 时间暴涨。
典型现象：filepath.Walk 耗时远超 find . -type f | wc -l；strace 显示大量重复的 lstat 和 openat；SSD 上仍卡顿，说明不是纯吞吐瓶颈，而是 I/O 并发度和路径解析开销问题。
替代方案：filepath.WalkDir（Go 1.16+）能解决什么？
filepath.WalkDir 不是简单“更快的 Walk”，它通过两个关键改进缓解 I/O 压力：一是避免对每个目录项都做两次 stat（Walk 先 stat 判断类型，再 Readdir；WalkDir 用 ReadDir 一次性获取含类型信息的 DirEntry）；二是支持提前跳过子树（返回 filepath.SkipDir 时不触发后续 openat）。
- 必须用
fs.DirEntry的Type()判断类型，而非os.FileInfo—— 后者会强制触发额外stat - 如果只需文件路径，用
entry.Name()拼接，别调entry.Info()，否则退化为Walk行为 - 在 SSD 或高 IOPS 文件系统上提速约 2–5×；HDD 上差异更明显
真正要并发？别直接 goroutine 包裹 Walk
对 filepath.Walk 或 WalkDir 的回调函数起 goroutine，不仅不能加速，反而因竞争文件描述符、内核 dentry 缓存失效、调度开销增大而更慢。真正的并发遍历需从底层控制目录打开粒度。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
可行做法是：用 os.ReadDir 手动读取一级目录，对每个子目录启动独立 goroutine（带限速），并在 goroutine 内使用 WalkDir —— 这样并发的是“目录层级”，不是“文件项”。注意：
- 限制 goroutine 数量（如
sem := make(chan struct{}, 8)），避免 fd 耗尽（Linux 默认 soft limit 通常 1024） - 不要在 goroutine 中直接拼接完整路径后调
os.Stat，这又回到单文件stat死循环 - 若需统计或过滤，优先用
DirEntry.Type()+ 名称匹配，避免任何Info()调用
遇到 symlink 循环或权限拒绝怎么办？
filepath.Walk 和 WalkDir 都默认不跟随 symlink，所以一般不会陷入无限循环；但若手动 os.Readlink + 递归，就极易出问题。权限错误（permission denied）则更常见——WalkDir 在无法读取某目录时，会把错误传给回调函数，此时返回 nil 继续，还是返回 filepath.SkipDir，取决于你的策略：
- 日志采集类场景：返回
nil，记录错误但不停止 - 构建工具类场景：返回具体 error（如
errors.Is(err, os.ErrPermission)），让外层中断并提示路径 - 绝对不要忽略 error 参数——
WalkDir的回调签名是func(path string, d fs.DirEntry, err error) error，err 为非 nil 时 d 可能为 nil
最易被忽略的一点：WalkDir 对根路径本身的 ReadDir 失败（比如根不存在或无读权限），根本不会进入回调，错误直接由 WalkDir 返回。这个顶层错误常被当成“没走回调”而误判为逻辑空转。
