Go os.ReadFile 与 Open 的大文件选择

os.ReadFile 适合大小受控、确实需要完整字节切片的文件；大文件只需顺序消费时，更适合 os.Open 后分块读取。关键不在 Open 这个名字，而在下游是否持续保留全文：Open 后再调用 io.ReadAll，仍然是整文件入内存。

官方地址：https://pkg.go.dev/os

假设归档任务只需要计算一个文件的摘要，小配置文件和数GB归档文件都能产生32字节SHA-256结果，但读取策略不应相同。这里把这两种写法放在同一个任务下比较，避免把“大文件”误解成一个固定大小门槛。示例围绕已稳定落盘的普通文件，不涉及不断增长的日志或管道。

ReadFile拿到全文，Open拿到读取能力

ReadFile 成功时返回完整内容和nil错误，正常读到结尾不会把EOF作为失败交给调用者。它管理内部打开和关闭，调用者不需要再关闭返回的字节切片。内容会保留到应用不再引用它、且运行时回收相关内存为止。

Open 返回只读文件对象 *os.File。后续读取、定位和关闭由调用者安排。打开成功不代表内容已经读完，更不保证后续读取不会失败。Open本身不会把整个文件加载到Go字节切片中。

只计算摘要，为什么还要保留全文？

对受控的小文件，最短实现足够清楚：

package digest

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

// DigestSmall只适合已知大小受控、允许整文件驻留内存的输入。
func DigestSmall(path string) ([32]byte, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return [32]byte{}, fmt.Errorf("read file: %w", err)
    }
    return sha256.Sum256(data), nil
}

但同样的写法用于体积未知的归档文件，会让内存需求随文件内容增大。摘要计算本身不需要保存前面所有字节，保留全文只是读取方式带来的成本。若同时处理C个文件，应把并发、每个文件的内存、解析对象和任务结果一起纳入预算，不能只看单文件能否在开发机上读完。

不存在通用的“超过10MB就必须Open”规则。如果消费者本来就要多次随机访问整份内存数据，而且大小可控，ReadFile可能更直接；如果任务只是复制、摘要或逐条解析，优先考虑流式消费。

用固定缓冲完成大文件摘要

下面的流式版本保持一个64 KiB读取缓冲和一个摘要状态。64 KiB只是示例参数，不是系统最佳值，也不是整个进程的内存上限。代码没有在本文环境执行，不附虚构耗时或吞吐率。

package digest

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

// DigestStream适用于已经稳定落盘、允许顺序读取到EOF的普通文件。
func DigestStream(path string) (sum [32]byte, err error) {
    f, err := os.Open(path)
    if err != nil {
        return sum, fmt.Errorf("open file: %w", err)
    }
    defer func() {
        // 优先保留读取错误；成功读取后仍报告关闭错误。
        if closeErr := f.Close(); err == nil && closeErr != nil {
            sum = [32]byte{}
            err = fmt.Errorf("close file: %w", closeErr)
        }
    }()

    h := sha256.New()
    buf := make([]byte, 64*1024) // 示例缓冲64 KiB，不随文件长度增长。
    for {
        n, readErr := f.Read(buf)
        if n > 0 {
            // Read可能同时返回有效数据和错误，只处理buf[:n]。
            if _, writeErr := h.Write(buf[:n]); writeErr != nil {
                return [32]byte{}, fmt.Errorf("hash data: %w", writeErr)
            }
        }
        if errors.Is(readErr, io.EOF) {
            break
        }
        if readErr != nil {
            // 非EOF错误时不返回部分文件的摘要作为成功结果。
            return [32]byte{}, fmt.Errorf("read file: %w", readErr)
        }
        if n == 0 {
            return [32]byte{}, io.ErrNoProgress
        }
    }
    copy(sum[:], h.Sum(nil))
    return sum, nil
}

buf 是复用缓冲，buf[:n] 才是本轮有效数据。即使底层一次Read没有填满缓冲，也不能把剩余空间当作新内容交给摘要器。摘要器 h 只保留计算状态，最终 sum 是固定长度数组。

正常结尾允许 n>0 与EOF一同返回，因此先处理有效字节，再判断结束条件。非EOF读取错误会返回失败，不把部分文件的摘要伪装为完整结果；零字节且无错误的分支也明确拒绝无进展。关闭逻辑放在打开成功之后登记，避免后续任何返回分支遗漏资源。

换成Open后，哪些地方仍可能占满内存？

第一种是再调用 io.ReadAll(f)。第二种是每读取一块就把它追加到永久增长的切片。第三种是把全部解析记录保存到内存集合，最终仍然让业务数据量决定峰值。流式读取减少的是原始输入的完整驻留，并不自动约束下游缓存。

如果把 buf[:n] 传给异步任务，必须明确所有权。下一轮Read会覆盖同一个底层数组，需要独立保留的数据应当复制，并同时限制队列容量，否则复制和积压会重新放大内存。这也是示例使用同步摘要器的原因。

也可以采用 io.Copy(h, f) 简化摘要消费。使用 io.CopyBuffer 时不要断言传入缓冲必然参与复制：官方文档指出，源实现WriterTo或目标实现ReaderFrom时，可能绕过该缓冲。本文直接展开Read循环，是为了清楚表达可复用片段的边界，不是宣称它比标准库复制更快。

文件大小和读取成功各自能说明什么？

事先Stat得到的Size可以帮助制定策略，但文件可能在检查后变化。单靠“先检查Size，再ReadFile”不能对可变输入提供严格的实际读取上限。需要硬性容量限制时，应在实际读取过程中累计字节数并明确拒绝条件。

ReadFile和Open都不会提供文件内容快照。摘要对应实际读取到的字节；文件同时被其他进程修改时，不能仅凭读取API承诺得到某一时刻的一致版本。归档文件应由生产方完成写入后再交付，或使用适合业务和文件系统的同步、快照与版本化机制。

相关问题

Open读取一定比ReadFile快吗？

不能这样判断。文件系统缓存、存储、读取块大小、并发和消费者计算都会影响结果。本文比较数据保留方式，不提供未经测量的性能排名。

大文本文件改用Scanner就足够了吗？

还需要考虑单条记录长度、扫描器配置和错误处理。它也不能替你限制保存下来的业务对象数量；文本分词问题和整文件内存问题应分别处理。

是否每次读取后都要Close？

一个文件对象处理完后关闭，通常不必每读一个块就重新打开。大批量循环应把单文件处理放进独立函数，避免所有defer都拖到外层函数最后才执行。

选择时先问消费者是否需要全文，再问允许多少并发和多大峰值。对只输出摘要的归档任务，Open配合同步分块消费能把原始输入的驻留量与文件长度分开；对大小受控的全文任务，ReadFile仍然有简洁明确的价值。

参考：os文件读取接口；io复制与缓冲语义；SHA-256包。