Go os.DirFS 怎样复用已有缓冲空间

Go os.DirFS 不接收缓冲区，也不负责替业务保存可复用的字节切片。要复用已有缓冲空间，应先通过目录视图打开文件，再把调用方持有的非空字节切片交给读取逻辑。对“连续处理多份文件、每次只消费一段数据”的任务，可以用同一块 buf 配合 io.CopyBuffer，等一份文件处理结束后再处理下一份。

例如，一个资料索引程序只需计算每份文本的摘要，没必要把每个文件的全部内容留在内存里。这里将目录访问与数据处理分开：目录视图可复用，每份文件单独打开和关闭，工作缓冲区由串行任务独占。

Go 官方地址：https://go.dev/

先确定缓冲区属于哪一层

os.DirFS 的参数是目录名，结果是 fs.FS。它解决的是“以这个目录为起点访问文件”，不是“把下一份文件写进上一次分配的切片”。因此，没有给 DirFS 追加 buf 参数的用法。

这张表只约束本文的程序设计；复用工作区不等于整个程序没有其他内存分配，也不能据此承诺吞吐量一定提高。

确认接口和适用范围

DirFS 自 Go 1.16 提供。本例围绕 fs.FS.Open 和 fs.File 的读取、查询元信息、关闭能力编写，所以 helper 接收 fs.FS，而不是把目录路径硬编码在 helper 内。调用方可以传入其他满足接口的文件系统，但仍要满足例子对普通文件的要求。

适用场景是同步、串行、流式消费。摘要计算在 Write 返回时已消费这段字节，不需要把整个文件保存为一份结果切片。若业务要求返回完整文件内容，工作区和最终结果的存储是两回事，应另作设计。

用一个缓冲区串行处理两份文件

在程序工作目录下自行准备 data 目录，其中放入 chapter-a.txt 与 chapter-b.txt 两个普通文本文件，内容可不同。以下是完整的 main.go 示例；它计算实际读到的内容摘要，不依赖预先给定的文件大小。

package main

import (
    "crypto/sha256"
    "fmt"
    "io"
    "io/fs"
    "os"
)

// 包装只暴露基本接口，使本例明确使用传入的工作区。
type readerOnly struct{ io.Reader }
type writerOnly struct{ io.Writer }

func hashFile(fsys fs.FS, name string, buf []byte) (sum string, count int64, err error) {
    // 非 nil 的零长度切片会让 CopyBuffer panic，在入口明确拒绝。
    if len(buf) == 0 {
        return "", 0, fmt.Errorf("缓冲区长度必须大于零")
    }
    f, err := fsys.Open(name)
    if err != nil {
        return "", 0, fmt.Errorf("打开 %s: %w", name, err)
    }
    // 每次 helper 返回就关闭文件；已有读取错误优先保留。
    defer func() {
        if closeErr := f.Close(); closeErr != nil && err == nil {
            sum = ""
            err = fmt.Errorf("关闭 %s: %w", name, closeErr)
        }
    }()
    info, err := f.Stat()
    if err != nil {
        return "", 0, fmt.Errorf("读取 %s 元信息: %w", name, err)
    }
    if !info.Mode().IsRegular() {
        return "", 0, fmt.Errorf("%s 不是普通文件", name)
    }
    // 每份文件使用新摘要对象，只有字节工作区在串行任务间复用。
    h := sha256.New()
    count, err = io.CopyBuffer(writerOnly{h}, readerOnly{f}, buf)
    if err != nil {
        return "", count, fmt.Errorf("读取 %s: %w", name, err)
    }
    return fmt.Sprintf("%x", h.Sum(nil)), count, nil
}

func run() error {
    // 示例使用自己控制的 data 目录和固定文件名。
    fsys := os.DirFS("data")
    buf := make([]byte, 32*1024)
    for _, name := range []string{"chapter-a.txt", "chapter-b.txt"} {
        digest, count, err := hashFile(fsys, name, buf)
        if err != nil {
            return err
        }
        // 输出的是示例程序将要计算的值，文章不预设文件内容或摘要。
        fmt.Printf("%s: %d 字节 SHA-256=%s\n", name, count, digest)
    }
    return nil
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

外层只分配一份 32 KiB 工作区。每次调用 hashFile 都等读取结束、关闭文件后才返回，下一次循环才能使用同一块内存。这里的大小是示例选择，不是最佳值或文件大小上限。空文件可以正常参与计算；缓冲区非空不要求文件也非空。

函数把打开、元信息和读取错误带回调用方，关闭失败也不会被静默当作成功。若读取中途出错，count 可以保留已复制的字节数，但空摘要和错误表示这次结果不可作为完整文件摘要使用。示例未在本文执行，不展示虚构输出。

明确快速路径与缓冲区所有权

io.CopyBuffer 有一个容易误解的行为：源支持 io.WriterTo，或目标支持 io.ReaderFrom 时，复制可能使用这些能力，传入的 buf 不参与复制。仅把文件以 io.Reader 接口变量保存，并不能抹掉底层动态类型的方法。

示例中的 readerOnly 和 writerOnly 是只嵌入基本接口的包装类型，分别只向复制器暴露 Read 和 Write。这样做是为了让这个“演示已有工作区复用”的例子走通用复制路径，不是在宣称所有文件复制都应该禁用快速路径。

另一个区别是 len 与 cap。make([]byte, 0, 32768) 容量虽大，长度仍是零，直接传给 CopyBuffer 会触发 panic。若这块切片确实由当前任务独占，可以先扩展到可用长度再传入；本例在 helper 入口要求 len 大于零，避免隐式分配与零长度混淆。nil 交给 CopyBuffer 会由它分配临时空间，也不符合“使用现有工作区”的演示目标。

不要让两个并发任务同时写同一个 buf。需要并行时，可以为每个 worker 分配一份独占缓冲区，或者在明确借还协议后再使用池；缓冲区归还后，借用者也不应继续读写。本文不加入池实现，以免把串行复用的问题扩展成资源调度。

按业务选择简化方案和安全边界

目录访问也有独立限制。DirFS 不能作为任意不可信目录内容的安全沙箱：符号链接可指向目录树外；相对目录还会受后续工作目录变化影响。本例只读取自己控制的目录和固定文件名，不把请求参数直接当作文件列表。需要限制符号链接越界访问时，应依据所用 Go 版本研究 os.Root 相关接口，而不是靠复用缓冲区解决访问控制。

同样，读取前的普通文件判断并不保证读取期间文件内容不变。本例计算的是实际读到的字节；若要求资料的版本一致性，应在业务上使用不可变版本或协调写入者。

常见问题

复用 DirFS 就能复用文件内容吗？不能。它只是目录视图，文件读取位置属于打开后的文件对象，内容缓冲区需要业务另行持有。

为什么工作区内容不能留到下一次调用后再用？下一份文件会覆盖相同底层数组。需要长期保存的数据必须拥有独立存储，摘要字符串则是本例生成的独立结果。

必须使用包装类型吗？不必。只有当你明确需要通用复制路径使用这块工作区时才采用此做法。普通文件传输可以先保留标准库的接口优化。

串行复用一定减少所有分配吗？只能说应用不必在每次 helper 调用时重新创建这份工作区。打开文件、创建摘要对象、格式化摘要和错误信息仍可能产生分配，本文不提供未经测量的性能结论。

官方文档：https://pkg.go.dev/os#DirFS；https://pkg.go.dev/io#CopyBuffer；https://pkg.go.dev/io/fs#File。目录与边界依据 os 文档，复制策略依据 io 文档，文件能力依据 io/fs 文档。