Go os.ReadDir 读取大目录怎么控内存：DirEntry 流式遍历与排序取舍

目录扫描工具一上线，最先暴露出来的往往不是文件打不开，而是进程内存随着目录大小一起往上走。很多代码直接调用 os.ReadDir，拿到完整的 []os.DirEntry 后再过滤；目录只有几千项时没问题，换成缓存目录或构建产物目录，排序和切片就会把峰值一起推高。

先把目录扫描做成一个可验收的小工具

这次的目标不是封装一个“万能文件搜索器”，而是做一个只统计指定目录下普通文件数量的扫描命令。它需要在目录不存在、权限不足、目录项过多时给出可判断的结果，并且能通过参数切换一次性读取和分批读取。

go mod init example.com/dirscan
go run . --root ./cache --mode batch --batch 256

这里的 --mode all 代表调用 os.ReadDir，--mode batch 代表打开目录后反复调用 File.ReadDir(256)。两条路径统计的是同一层目录，不递归进入子目录，这样对比才不会被遍历深度干扰。

为什么 os.ReadDir 会把排序和内存一起带进来

os.ReadDir 是一个方便的高层入口：它打开目录、读取全部目录项，并按文件名排序后返回。这个排序特性很适合生成稳定的列表，但代价也很明确——调用返回前，程序必须持有完整结果。

如果目录里有 30 万个条目，[]os.DirEntry 本身只是切片骨架，底层目录信息、文件名字符串和运行时分配才是主要开销。不要只盯着切片长度；文件名越长、类型信息越复杂，堆分配越容易出现明显差异。

需要稳定顺序时可以保留这个 API，但应把它当作“全量加载”而不是“流式读取”。例如生成一次性的索引文件、需要展示完整排序结果的管理页，使用 os.ReadDir 更直观。

一次性读取适合哪些边界

用 File.ReadDir 按批次收口内存峰值

批量模式的关键是把“打开目录”和“读取一批”分开。File.ReadDir(n) 传入正数时，最多返回 n 个目录项；读到末尾时返回的错误是 io.EOF，它表示正常结束，不应该被当成扫描失败。

func countRegularFiles(root string, batch int) (int, error) {
    if batch 

每一轮只保留当前批次的 entries。下一轮赋值后，上一批不再被业务引用，垃圾回收可以回收它的临时空间。这里使用 entry.Type().IsRegular() 只做快速类型判断；如果必须确认符号链接目标或精确模式，再考虑 entry.Info()，但那会增加系统调用和失败分支。

EOF、空批次和中途错误不能混为一谈

不要写成“只要 err != nil 就立即返回”。最后一批可能同时带着少量条目和 io.EOF，应该先处理已经返回的条目，再把 EOF 当作正常收尾。相反，权限变化、文件系统断开等其他错误需要保留已知错误信息，让上层决定是否重试。

排序取舍：省内存和稳定输出不能同时白拿

File.ReadDir(n) 的批次顺序不应被当作全局文件名顺序。若页面只显示“最近匹配到的 50 个普通文件”，可以边读边筛选，使用堆或保留候选集；若需求是按文件名输出全部条目，最终仍需要排序，批量读取只降低了读取阶段的瞬时占用，并不会消除排序的总成本。

比较稳妥的决策是先写清结果契约：

• 只要计数、过滤或遇到第一个匹配项：使用批量遍历，不排序。
• 需要前 50 项：批量读取，维护固定大小的候选集，最后只排序候选集。
• 需要全部按名称导出：接受全量数据成本，或者把结果写入临时文件后做外部排序。

本地验收：看结果，也看内存曲线

先用同一个目录分别运行两种模式，确保计数一致：

go run . --root ./cache --mode all
go run . --root ./cache --mode batch --batch 256
go test ./...
go test -bench . -benchmem

测试至少覆盖空目录、只有子目录的目录、批次大于条目数、批次为 0、目录不存在，以及读取过程中出现权限错误的场景。性能验收不要只看单次耗时；把目录规模逐步扩大，观察堆分配次数和进程 RSS 是否随条目数线性抬升。

如果扫描被放进 HTTP 请求里，建议把批次大小做成受控配置，而不是允许请求参数任意传入。256 或 512 可以作为初始实验值，最终仍以目标机器、文件名长度和并发量下的基准结果为准。

常见问题

File.ReadDir(0) 是不是表示一次读完？

是。传入 0 时会读取剩余全部目录项；想控制批次应传入正整数，例如 256。

批量读取后还需要手动关闭目录吗？

需要。通过 os.Open 得到的 *os.File 应用 defer f.Close() 关闭；这和是否分批读取无关。

为什么批量模式不一定比 os.ReadDir 快？

批量模式主要解决峰值内存和可控处理，不保证总耗时更低。若最终仍要把所有条目拼接、排序，额外的循环和排序可能抵消收益。

读取目录时遇到 io.EOF 应该记录错误吗？

在 ReadDir(n) 的正数批量语义下，读到末尾的 io.EOF 是正常结束；其他错误才应进入失败记录或重试流程。

把选择写进代码，而不是写进经验

小目录和稳定排序优先时，os.ReadDir 是清楚的默认选择；大目录扫描、统计和过滤优先时，File.ReadDir(n) 更容易把内存上限控制住。真正上线前，把目录规模、文件名特征、并发数和排序要求放进基准测试，结果比“哪个 API 更快”的泛泛结论可靠得多。