filepath.walk在深层嵌套时变慢，因其为每个文件/目录重复调用os.stat且不复用父目录fileinfo；应改用go 1.16+的filepath.walkdir配合fs.direntry优化性能。
为什么 filepath.Walk 在深层嵌套时变慢？
因为默认实现会为每个文件/目录调用一次 os.Stat，而深层路径（如 /a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p）导致大量重复的路径拼接与系统调用开销；更关键的是，filepath.Walk 不复用父目录的 os.FileInfo，每次进入子目录都重新 stat 父路径。
实操建议：
- 改用
filepath.WalkDir（Go 1.16+），它通过fs.DirEntry避免多数Stat调用，尤其对目录项只需判断是文件还是子目录时，性能提升可达 3–5 倍 - 若需完整
os.FileInfo（比如读取修改时间），只对目标文件调用entry.Info()，跳过中间目录 - 避免在
WalkDir回调中做阻塞操作（如网络请求、大文件读取），否则会拖慢整个遍历
如何跳过符号链接和权限不足目录而不中断扫描？
filepath.WalkDir 默认不会自动跟随符号链接，但遇到 permission denied 会直接返回错误并终止——这不是你想要的“尽力扫描”。
实操建议：
- 用
errors.Is(err, fs.ErrPermission)检查错误类型，返回filepath.SkipDir继续遍历兄弟路径 - 对符号链接，用
entry.Type() & fs.ModeSymlink != 0判断，按需跳过或显式解析（filepath.EvalSymlinks） - 不要用
os.ReadDir+ 手动递归替代WalkDir，除非你需要完全控制顺序或并发粒度；手动实现容易漏掉SkipDir语义，导致 panic 或死循环
并发扫描多个根目录时，怎样避免 goroutine 泄露和资源争用？
直接为每个根路径起一个 go walk(...) 并发执行，看似高效，但没设限会导致瞬间创建数百 goroutine，压垮文件描述符或内存。
实操建议：
- 用带缓冲的
chan fs.PathError收集错误，配合sync.WaitGroup控制生命周期 - 限制并发根目录数（如最多 4 个），用
sem := make(chan struct{}, 4)做信号量，每次进 goroutine 前sem ，退出时 <code> - 共享的输出通道（如
chan FileInfo）必须有足够缓冲（make(chan FileInfo, 1000)），否则发送方可能阻塞在深度遍历中途 - 别在回调里直接往数据库或日志写入——攒批提交，或用单独 goroutine 消费结果通道
WalkDir 的 DirEntry 为何有时返回空 name()？
这是常见误用：调用 entry.Name() 是安全的，但若你用 entry.Info().Name()，而该 entry 是目录且未被 Readdir 过，Info() 可能触发额外 stat 并在某些文件系统（如 NFS、FUSE）上返回空名或错误。
实操建议：
- 始终优先用
entry.Name()获取文件名，它不触发系统调用 - 需要类型或大小等元信息时，先检查
entry.Type()，仅对文件调用entry.Info()；对目录，通常不需要Info() - 若必须获取目录的修改时间，用
os.Stat(entry.Name())（注意传入的是相对名，不是完整路径），或在 WalkDir 前先os.Stat根路径存好基础信息
真正影响吞吐的往往不是算法，而是对 DirEntry 生命周期的理解和对错误流的处理方式。很多人卡在 “为什么加了 goroutine 反而更慢”，其实只是没意识到 os.FileInfo 的惰性加载机制和文件系统缓存行为不一致。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
