Go bufio.Scanner怎样提高单行扫描的最大长度怎样在批处理代码中减少额外分配

批处理程序用 bufio.Scanner 按行读文件时，默认配置并不适合超长记录：Scan() 会在 token 放不进缓冲区时停止。解决方案是先用 Scanner.Buffer 设定一个有边界的最大行长，再在只处理当前行的路径使用 Bytes()，避免每次循环都把字节复制成新字符串。

先确认长行为什么会让 Scan 停止

NewScanner 默认使用 ScanLines，并把最大 token 缓冲设为 bufio.MaxScanTokenSize，当前官方实现中它是 64 KiB。扫描器会逐步扩大内部缓冲；当缓冲已达到上限、仍然没有形成完整 token 时，Scan() 返回 false，这时必须检查 Err()，不能把它直接当成正常 EOF。

对按行读取来说，完整 token 还可能包含换行边界，所以“允许 64 KiB”不等于“每一行一定能有 65536 个业务字节”。批处理入口应先决定一个可接受的单行上限，并把超限当成输入质量问题处理。

package main

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

func main() {
    // 构造一行超过默认上限的示例输入，便于观察错误分支。
    input := strings.NewReader(strings.Repeat("x", 70*1024) + "\n")
    scanner := bufio.NewScanner(input)

    // Buffer 尚未配置时，长行可能触发 token too long。
    for scanner.Scan() {
        fmt.Println(len(scanner.Bytes()))
    }
    if err := scanner.Err(); err != nil {
        // EOF 会被 Scanner.Err 转换为 nil，真正的扫描错误要显式处理。
        fmt.Println("扫描失败:", err)
    }
}

用 Buffer 把长行上限写进实现

关键调用必须放在第一次 Scan() 之前。初始切片的容量决定扫描器可以直接使用的空间，max 则限制它允许分配或扩展到的最大缓冲。对长度比较稳定的批处理文件，可以让两者相等，减少扫描过程中反复扩容。

package main

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

func readLongLines(text string) error {
    scanner := bufio.NewScanner(strings.NewReader(text))

    // 预留 256 KiB；max 给输入设置 1 MiB 的单行硬上限。
    // Buffer 必须早于 Scan，否则会触发 panic。
    initial := make([]byte, 0, 256*1024)
    scanner.Buffer(initial, 1024*1024)

    for scanner.Scan() {
        // Bytes 只在当前迭代内使用，避免 Text 额外创建 string。
        line := scanner.Bytes()
        fmt.Println("当前行字节数:", len(line))
    }
    if err := scanner.Err(); err != nil {
        // 超过 1 MiB 或底层读取失败都从这里返回。
        return fmt.Errorf("读取批处理文件失败: %w", err)
    }
    return nil
}

func main() {
    // 真实代码可把 text 换成 os.File 或网络流 Reader。
    if err := readLongLines(strings.Repeat("record", 100)); err != nil {
        fmt.Println(err)
    }
}

不要把 max 盲目设成几百 MiB。Scanner 会在需要时逐步增长，但上限越大，恶意或异常输入一次占用的内存也越多。若能从业务协议得到最大记录长度，按协议上限再留出少量余量更稳妥。

批处理循环里怎样减少额外分配

Scanner.Bytes() 返回最近一次扫描得到的字节切片，不会额外分配；Scanner.Text() 会把当前 token 转成新字符串。只做校验、分隔、哈希或立即写入下游时，可以让处理函数接收 []byte。但这个切片的底层数组会被下一次 Scan() 复用，不能直接放进跨循环保存的结果集合。

func process(scanner *bufio.Scanner) ([][]byte, error) {
    var kept [][]byte
    for scanner.Scan() {
        // 当前行只在本轮使用，直接交给处理函数不会产生 Text 的字符串分配。
        line := scanner.Bytes()
        if len(line) == 0 {
            continue
        }
        if len(line) > 1 && line[0] == '#' {
            // 注释行只读不存，下一轮 Scan 后这块缓冲可复用。
            continue
        }

        // 需要跨越下一次 Scan 保存时必须复制，避免内容被覆盖。
        kept = append(kept, append([]byte(nil), line...))
    }
    if err := scanner.Err(); err != nil {
        // 返回错误时由调用方决定是否丢弃已经收集的结果。
        return nil, err
    }
    return kept, nil
}

“减少额外分配”不是“完全零分配”：上面的 kept 明确选择了为长期保存的记录复制字节。若下游 API 只接受字符串，应该在真正需要字符串的边界转换，而不是在扫描循环最前面对每行无条件调用 Text()。

参数与边界怎么选

最后再检查两件事：所有 Buffer 调用都在扫描开始前；所有 Scan() 结束路径都读取 Err()。如果输入可能出现无法接受的巨长行，不要只把上限调到很大后继续运行，而应记录行长、拒绝记录或切换到更可控的读取策略。

常见问题

把 max 设置成 1 MiB 后，为什么仍可能读不到 1 MiB 的业务内容？

max 限制的是扫描缓冲，不是纯业务字段长度；分隔符和 token 形成方式也会占用空间，因此应给换行等边界留余量。

可以在第一次 Scan 之后再调用 Buffer 吗？

不可以。Scanner 已经开始扫描后调用 Buffer 会 panic，应在创建 Scanner 后立即配置。

什么时候应该放弃 Scanner 改用 Reader？

当单行长度不可控、需要在超长记录后继续读取，或需要更细的错误恢复和分段策略时，bufio.Reader 更合适。