os.readdir 卡住是因为默认一次性加载全部目录项导致内存暴涨和 gc 压力大；应改用 syscall.getdents 流式读取或分批 channel 消费，避免全量驻留内存。
os.ReadDir 读取海量文件为什么卡住？
不是 Go 慢，是 os.ReadDir 默认行为在目录含数万+ 文件时会一次性分配并填充整个 []fs.DirEntry 切片，内存暴涨、GC 压力大、甚至触发 runtime: out of memory。尤其在 NFS 或远程挂载目录下，单次 syscall 返回延迟叠加，感知更明显。
常见错误现象：程序卡在 os.ReadDir 不返回；RSS 内存瞬间飙升几 GB；pprof 显示大量 runtime.makeslice 调用。
- 别用
os.ReadDir一次性加载全部条目 —— 它不支持流式迭代 - 避免
filepath.WalkDir配合全局计数器或切片收集 —— 同样全量驻留内存 - 真实需求通常是“遍历处理”，而非“先拿到全部再处理”，流式才是正解
用 syscall.Getdents 替代标准库（Linux only）
绕过 Go 标准库封装，直接调用底层 getdents64 系统调用，按需读取目录项，内存恒定（通常 8KB 缓冲足矣），速度提升 3–5 倍。适用于 Linux 服务器环境（如日志归档扫描、对象存储元数据同步）。
关键点：
- 用
golang.org/x/sys/unix调用unix.Getdents，传入固定大小[]byte缓冲区 - 每次调用返回若干
unix.Dirent，需手动解析 name 和 type（d_type字段比Stat()快得多） - 跳过
.和..，对DT_DIR/DT_REG做快速过滤，避免后续os.Stat开销 - 注意：Windows/macOS 不支持，跨平台项目慎用
分批 + channel 流式消费，控制内存与节奏
即使不用 syscall，也能用标准库实现可控流式。核心是把“读目录”和“处理文件”解耦，避免堆积。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
- 开一个 goroutine 专用读目录，每次调
os.ReadDir但只读固定数量（如 1000 个条目），发到chan fs.DirEntry - 消费者 goroutine 从 channel 拿条目，立即处理（如提取文件名、校验 size、丢弃不需要的类型）
- channel 设小缓冲（如
make(chan fs.DirEntry, 128)），防止生产者太快压爆内存 - 若需并发处理，worker 数量设为 2–4，远高于此反而因锁竞争（
os.File内部 fd 表争抢）而变慢
为什么 mmap 或并发读目录没用？
目录不是文件，不能 mmap；且目录结构由文件系统维护，其读取本质是顺序 I/O，不是随机访问场景。盲目启一堆 goroutine 并发调 os.ReadDir 同一目录，只会加剧内核 dcache 锁竞争，实测在 ext4 上吞吐下降 40%+。
真正有效的并发，只发生在「多目录并行」——比如扫描 /data/shard-001/ ~ /data/shard-100/，每个 shard 独立 os.ReadDir，这才是安全的横向扩展。
最后提醒：如果目录里有大量小文件（getdents 的优势最明显；如果混着超大文件（>1GB），重点应放在后续打开/读取优化上，目录扫描本身已不是瓶颈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
