go 1.16+ 应优先用 filepath.walkdir 而非 filepath.walk，因其避免重复 os.stat、天然规避符号链接循环、支持原生 filepath.skipdir 且错误处理更明确；filepath.walk 易因权限错误静默终止、符号链接卡死或性能下降。
直接用 filepath.Walk 是安全的，但它不是“最推荐”的选择——Go 1.16+ 应优先用 filepath.WalkDir，否则容易踩性能、符号链接和错误控制三类坑。
为什么 filepath.Walk 可能静默失败或卡死
filepath.Walk 内部对每个路径都调用 os.Stat，这会触发系统调用；遇到符号链接循环（如 a → b → a）时，它不主动检测，仅依赖内核层的嵌套限制（通常 40 层），可能卡住或 panic。权限错误（operation not permitted）传入回调后，若你没显式判断并返回 nil，整个遍历就提前终止——看起来像“静默失败”，其实是你漏了错误分支。
- 常见现象：
/proc/1/fd或容器挂载点报错后遍历戛然而止 - 正确处理：检查
err != nil后，用os.IsPermission(err) || os.IsNotExist(err)判断是否可跳过，是则返回nil，否则返回err - 别在回调里
panic或log.Fatal，那会杀掉整个 goroutine
filepath.WalkDir 才是 Go 1.16+ 的首选
filepath.WalkDir 返回 fs.DirEntry，复用 ReadDir 结果，避免重复 os.Stat，实测快 2–5 倍；默认不跟随符号链接，天然规避软链环路风险；支持精准跳过子树（返回 fs.SkipDir），而 filepath.Walk 的 filepath.SkipDir 有时会失效。
- 回调签名是
func(path string, d fs.DirEntry, err error) error，注意参数类型不同 - 轻量判断用
d.IsDir()和d.Type() & os.ModeSymlink != 0，别调d.Info().IsDir()—— 那会多一次os.Stat - 想跟随符号链接？得手动
os.Readlink(path)+filepath.Join(filepath.Dir(path), target)，再决定是否递归
回调里最容易写错的三件事
所有逻辑都在回调函数里，但多数人忽略变量复用、路径拼接和文件打开时机。
-
path是循环变量，直接传进 goroutine 会出错：必须写成p := path再启动 goroutine - 拼子路径别用
path + "/sub"，Windows 下崩；一律用filepath.Join(path, "sub") - 别在回调里对每个文件都
os.Open：先用d.Info().Size()快速过滤超大文件，真正需要内容时才打开
深度控制和过滤逻辑不能靠 Walk 自带
filepath.Walk 和 filepath.WalkDir 都不提供深度参数或内置过滤器。想只遍历两层？得自己算分隔符数量：strings.Count(path, string(filepath.Separator))；想跳过 .git？得在回调里匹配 filepath.Base(path) == ".git" && d.IsDir() 并返回 fs.SkipDir。
- 扩展名判断别用
filepath.Ext(path)：它从后往前扫描，大目录下开销明显；改用strings.HasSuffix(d.Name(), ".go") - 隐藏文件（以
.开头）需手动检查strings.HasPrefix(d.Name(), ".") - 并发处理要另起 goroutine 池，别在回调里直接
go process(p)——filepath.WalkDir本身非并发安全
真正难的不是调用哪个函数，而是把错误分类（权限 / 不存在 / 其他）、把路径处理解耦（拼接 / 截取 / 判断）、把 I/O 推迟到必要时刻——这些细节不写进回调里，就永远在修“遍历突然停了”或“CPU 跑满不动了”的 bug。
