Go Scanner 与 Reader 处理大文件的选择依据

处理大文件时，文件总大小通常不是 Go bufio.Scanner 和 bufio.Reader 的决定因素，单条记录的长度、分隔方式以及你要不要控制读取错误才是关键。短行、规则文本优先用 Scanner；可能出现超长行、需要保留分隔符或必须逐块恢复时，用 Reader 更稳妥。

官方文档：https://pkg.go.dev/bufio

先看记录边界，再决定 Scanner 还是 Reader

“大文件”只代表输入总量大，不代表必须把整个文件放进内存。两种类型都可以从 io.Reader 流式读取，差别在于每次交给业务的单位：Scanner 交付一个 token，Reader 让调用方自己决定按字节、按分隔符还是按片段消费。

Scanner 的限制在单条 token，而不是文件总大小

Scanner 会持续从输入中取得 token，不需要一次装入整个文件。默认 split 函数是 ScanLines，但文档给出的默认最大 token 缓冲是 MaxScanTokenSize = 64 * 1024；超长行可能让扫描不可恢复地停止。因此，读几十 GB 的许多短行并不是问题，读一条很长的 JSON 或 SQL 行才是风险。

package main

import (
    "bufio"
    "fmt"
    "io"
    "strings"
)

func scanLines(r io.Reader) error {
    scanner := bufio.NewScanner(r)
    // 先设置上限，再开始 Scan；max 要覆盖单条记录和可能的换行字节。
    scanner.Buffer(make([]byte, 32*1024), 2*1024*1024)
    for scanner.Scan() {
        // Text 会返回当前 token 的字符串副本，适合交给本轮业务处理。
        line := scanner.Text()
        fmt.Println(len(line))
    }
    // EOF 会被视为正常结束，其他读取错误由 Err 返回。
    return scanner.Err()
}

func main() {
    err := scanLines(strings.NewReader("短行\n另一行\n"))
    if err != nil {
        fmt.Println("读取失败:", err)
    }
}

Buffer 必须在扫描开始前调用；它解决的是 token 上限，不会让 Scanner 变成可任意恢复的分块解析器。如果记录长度无法可靠估计，或者超过上限后还要继续处理后续内容，应该改用 Reader。

Reader 适合长记录、分隔符和更细的错误判断

Reader.ReadString(delim) 和 ReadBytes(delim) 会读到分隔符；如果输入在找到分隔符前结束，它们仍会返回已经读到的数据和错误。这个返回约定很适合处理“最后一行没有换行”的文件：先消费非空数据，再把 io.EOF 视为输入结束。

package main

import (
    "bufio"
    "fmt"
    "io"
    "strings"
)

func readLines(r io.Reader) error {
    reader := bufio.NewReaderSize(r, 64*1024)
    for {
        // ReadString 会保留分隔符；没有结尾换行时仍可能返回最后一段内容。
        line, err := reader.ReadString('\n')
        if len(line) > 0 {
            fmt.Printf("记录长度=%d\n", len(strings.TrimSuffix(line, "\n")))
        }
        if err == io.EOF {
            // 最后一条无换行记录已经处理，正常结束读取。
            return nil
        }
        if err != nil {
            // 非 EOF 错误需要交给上层决定是否重试或终止。
            return err
        }
    }
}

如果不希望每次返回一条完整字符串，可以进一步使用 ReadSlice 或 ReadLine 逐段处理，但要牢记切片可能在下一次读取后失效；需要跨越下一次读取保存内容时，改用 ReadBytes、ReadString 或主动复制。

用四个问题完成项目里的选择

可以把最终决策固定成四个问题：第一，单条记录是否稳定小于 Scanner 的配置上限；第二，默认按行或自定义 token 是否已经足够；第三，是否需要保留分隔符、读取片段或查看缓冲区；第四，遇到半条记录和非 EOF 错误时，业务是否需要自行决定恢复方式。

四个答案都偏简单时，用 Scanner，并把 scanner.Err() 纳入收尾处理；只要超长记录、分隔符语义或错误恢复是核心需求，就用 Reader。无论选择哪一种，文件本身仍然可以按流读取，关键是不要把“总文件很大”和“单条记录很大”混为一谈。

• 短记录、固定 token：Scanner。
• 长记录、需要分隔符或缓冲控制：Reader。
• 边界不确定：优先选择能保留部分数据并让上层决定的读取方式。

常见问题

Scanner 读大文件一定会占满内存吗？

不会。它按 token 读取，文件总大小不是默认缓冲上限；真正需要关注的是单个 token 的长度和你设置的 Buffer 上限。

把 Scanner.Buffer 调大后就不用 Reader 了吗？

不一定。能估计上限且只需要 token 的场景可以继续用 Scanner；如果还要分段恢复、保留分隔符或控制错误处理，Reader 的接口更合适。

Reader.ReadString 遇到 EOF 要不要丢弃返回内容？

不要直接丢弃。若返回的字符串非空，应先处理最后一段，再根据 err == io.EOF 正常结束。