优先用filepath.WalkDir而非filepath.Walk，因其返回fs.DirEntry避免重复os.Stat开销，支持原生filepath.SkipDir跳过子目录，且能安全处理权限错误和nil DirEntry；单层枚举用os.ReadDir更轻量。
Go 语言实现高性能目录扫描，关键不在“并发越多越快”，而在于选对 API、避开 stat 开销、正确处理错误边界。用错 filepath.Walk 或盲目套 fastwalk 反而更慢、更容易 panic。
为什么优先用 filepath.WalkDir 而不是 filepath.Walk
filepath.WalkDir 是 Go 1.16+ 的标准递归方案，性能和可控性都明显优于 filepath.Walk。核心差异在元数据获取方式：
-
filepath.Walk对每个路径强制调用os.Stat，哪怕你只关心文件名——大量小文件下系统调用开销爆炸 -
filepath.WalkDir默认只返回fs.DirEntry，d.Name()和d.IsDir()都不触发 stat；真需要大小或时间戳时，再显式调用d.Info() -
filepath.SkipDir在WalkDir中是原生支持的；而在Walk中只能靠路径拼接模拟，容易漏判或误跳 - 权限错误（如
os.ErrPermission）传入回调时，WalkDir的d参数可能为nil，必须先判空再用，否则直接 panic
os.ReadDir 适合什么场景？怎么避免常见 crash
单层目录快速枚举就用 os.ReadDir，它比 filepath.WalkDir 更轻——不递归、无深度管理、零 stat 开销。但它不是“安全兜底”方案：
- 它只读当前目录一级，返回
[]fs.DirEntry；想递归得自己写逻辑，但别手写带符号链接循环检测的递归 - 路径拼接必须用
filepath.Join(root, entry.Name())，硬拼root + "/" + name在 Windows 下会失效 - 遇到权限错误时，
os.ReadDir直接返回非 nilerr，不继续执行后续代码；没检查就直接 range，会导致 panic - 如果只需要文件名列表或判断类型，别对每个 entry 都调
entry.Info()——那是自找 stat 开销
用 fastwalk 加速前，先确认你真需要它
fastwalk 确实比标准库快 2–6 倍，但它不是“开箱即用”的银弹：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 它默认并发遍历子目录，但在 SSD 上收益有限，在 HDD 或网络文件系统上反而因随机 IO 拖慢整体速度
- 它不自动跳过权限错误；遇到
/proc或/sys这类特殊目录时，需手动捕获并return nil，否则整个 walk 中断 - 符号链接处理需显式配置
Config.Follow，默认不跟随；若开启又没做环路检测，可能卡死 - 它返回的是
fs.DirEntry，和filepath.WalkDir接口一致，但不兼容filepath.SkipDir——跳过子目录得靠回调里return nil+ 外部状态标记，逻辑更重
过滤逻辑必须放在 walk 回调里，而不是事后处理
高性能扫描的核心之一是“边走边筛”，而不是把所有路径先 collect 到 slice 再 filter——内存和时间双浪费：
- 排除
.git或node_modules：检查d.IsDir() && d.Name() == "git"，然后return filepath.SkipDir；别用strings.Contains(path, ".git")，会误杀mygitfile.txt - 按扩展名过滤（如
.go）：用strings.HasSuffix(d.Name(), ".go")，比filepath.Ext(path)更快且不依赖完整路径解析 - 隐藏文件判断：统一转小写后比对
strings.HasPrefix(strings.ToLower(d.Name()), ".")，覆盖.DS_Store、desktop.ini等 - 深度限制：用闭包变量计数，每进一层目录加 1，超限时
return filepath.SkipDir；别依赖strings.Count(path, string(filepath.Separator))，路径含空格或特殊字符时易出错
真正影响性能的从来不是 goroutine 数量，而是 stat 调用次数、错误未处理导致的 panic、以及路径操作跨平台失效。写完扫描逻辑后，先用 /tmp 下含 1000 个空文件的目录测 baseline，再换真实项目目录验证——很多“慢”问题其实出在 d.Info() 被无脑调用了几十万次。
