os.readdir比filepath.walkdir更适合大目录，因其返回轻量direntry切片、零stat调用；需手动处理符号链接与权限错误；并发应按物理设备分组而非盲目增加goroutine；缓存策略须匹配业务更新频率；超大目录需避免内存压力。
处理万级甚至十万级文件的目录时，Go 默认的 filepath.Walk 或逐个 os.Stat 会迅速卡死——不是代码写错了，而是系统调用频率直接打满内核调度能力。关键不在“怎么遍历”，而在“怎么避免反复进内核”。
为什么 os.ReadDir 比 filepath.WalkDir 更适合大目录
os.ReadDir 返回的是轻量级 fs.DirEntry 切片，不触发任何 stat(2) 系统调用；而 filepath.WalkDir 在回调中默认调用 entry.Info() 才能拿到文件大小、类型等，这等于对每个条目又做一次 stat。
- 只列名字/判断类型（目录 or 文件）：直接用
entry.IsDir()或entry.Type()，零系统调用 - 需要 size/mtime：仅对真正要处理的条目显式调用
entry.Info()，避免全量加载元数据 - 注意
os.ReadDir不递归，如需深度遍历，自己用栈或队列管理路径，可控性更强
遍历中跳过符号链接和权限错误的硬坑
遇到符号链接循环或 Permission denied 时，filepath.WalkDir 默认会 panic 或中断整个遍历。它不会自动跳过，必须在 WalkDirFunc 中手动拦截并返回 filepath.SkipDir 或忽略错误。
- 检查是否为符号链接：
info, _ := os.Lstat(path); if info.Mode()&os.ModeSymlink != 0 { return filepath.SkipDir } - 权限错误不能只靠
os.IsPermission：NFS 或容器挂载点可能返回syscall.EACCES，需额外判断errors.Is(err, syscall.EACCES) - 不要在遍历中直接
log.Fatal—— 一个子目录权限失败不该 kill 整个程序
并发扫描目录时，I/O 瓶颈比 CPU 更致命
启动 10 个 goroutine 并行读不同子目录，看似合理，但若这些子目录物理上落在同一块机械硬盘或同一 NVMe namespace，磁头寻道或队列竞争反而让总耗时翻倍。
- 先用
os.ReadDir获取全部子目录名，再按磁盘分区/挂载点分组，把同物理设备的路径塞进同一个 goroutine - 限制 goroutine 数量：通常设为
runtime.NumCPU()的 1–2 倍即可，再多只是增加调度开销 - 对单个超大目录（如含 5w+ 文件），别拆成多个 goroutine 去
readdir(3)—— 内核的getdents64本身是原子批量返回的，拆了反而破坏缓存局部性
缓存策略必须和业务更新频率对齐
文件系统元数据缓存不是越长越好。AttrTimeout: time.Second * 5 对静态归档目录很稳，但对实时日志目录就是灾难：刚写入的新文件可能被缓存“隐身”几秒。
- 高频变更目录：把
AttrTimeout和EntryTimeout降到100ms以内，甚至设为0（每次强制刷新） - 只读归档目录：可设到
time.Minute * 10，大幅降低stat和readdir调用频次 - 注意
os.ReadDir本身不走 FUSE 缓存，它绕过用户态文件系统，直通内核 VFS —— 所以 FUSE 的缓存配置对它无效
最常被忽略的一点：目录项数量本身就会压垮内存分配器。当 os.ReadDir 返回 10w 个 DirEntry，底层其实是分配了一个大 slice，且每个 DirEntry 的 name 字段是独立字符串——这比想象中更吃 GC 压力。真要处理百万级目录，得自己用 unix.Getdents + 自定义解析，否则光初始化就卡住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
