小文件索引遍历慢的核心在于频繁 os.stat 和目录解析开销；提速关键为跳过元数据加载、复用 fs.direntry、用外部 db 索引替代实时遍历，并避免回调中调用 d.info() 或冗余路径操作。
小文件索引遍历慢，核心问题不在 Go 代码逻辑，而在频繁触发 os.Stat 和目录项解析开销；真正有效的提速方式是跳过元数据加载、复用 fs.DirEntry、并用外部索引替代实时遍历。
为什么 filepath.WalkDir 仍然慢？
很多人改用 filepath.WalkDir 后发现性能提升有限，原因往往出在回调里偷偷调用了 os.Stat 或 d.Info()——这会让原本零开销的 d.IsDir() 变成一次完整系统调用。实测中，一个含 5 万小文件的目录，只要回调里有 1 次 d.Info()，耗时就从 120ms 拉到 800ms+。
- 只判断类型或名称：直接用
d.Name()和d.IsDir()，不碰d.Info() - 需要大小/时间戳才调用
d.Info()，且应加 error 判断（err != nil时可能因权限失败） - 避免在循环里拼接完整路径再
os.Stat——这等于把WalkDir降级回老版Walk
os.ReadDir 手动递归比 WalkDir 更快？
是的，在纯路径收集场景下，os.ReadDir + 手动栈/队列递归通常比 filepath.WalkDir 快 10%～15%，因为它完全绕过 fs.WalkDirFunc 的函数调用开销和路径字符串传递成本。
- 用
sync.Pool复用[]fs.DirEntry切片，避免每次分配 - 子目录入栈前先做白名单过滤（如跳过
"node_modules"、".git"），减少无效递归 - Windows 下拼路径用
filepath.Join(parent, name)，别用path.Join（它更重） - 若只关心文件名匹配（如找
"config.json"），直接比对entry.Name()，不要构造全路径
真正想快，就别遍历文件系统
当小文件数超过 10 万，且需高频随机查找（比如“查某 ID 对应的附件路径”），硬遍历目录树已不可取。此时应放弃实时 os.ReadDir，改用预建索引：
- 首次扫描后，把所有小文件路径 + 元数据写入 LevelDB/BadgerDB，key 为文件哈希或业务 ID，value 包含相对路径和 mtime
- 后续查询走 DB
Get，耗时稳定在微秒级，不再依赖磁盘结构 - 用
fsnotify监听新增/删除，增量更新索引，避免全量重扫 - 注意：DB 存的是逻辑路径（如
"user/123/avatar.jpg"），不是物理路径；真实存储可合并进容器文件（如.merge），索引只管映射
最易被忽略的一点：即使用了 os.ReadDir，如果在每层递归里都调用 filepath.Clean 或反复 filepath.Abs，这些字符串操作在百万级条目下会吃掉可观 CPU。提前算好根路径并复用，比任何并发优化都实在。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
