bufio.Scanner默认64KB缓冲限制导致超长行报错，需用scanner.Buffer()设最大上限；替代方案有ReadString（无长度限制）和Read（逐块处理，需手动拼接）。
bufio.Scanner默认有64KB缓冲限制，读超长行会报bufio.Scanner: token too long
这是最常遇到的错误。默认情况下，Scanner只允许单行不超过64KB（即bufio.MaxScanTokenSize），一旦某行（比如日志中带大段base64或JSON）超过该长度，就会直接失败并终止扫描。
解决方法是显式调大缓冲区上限：
scanner := bufio.NewScanner(file) scanner.Buffer(make([]byte, 0, 64*1024), 10*1024*1024) // 初始0，最大10MB
注意两个参数：make([]byte, 0, 64*1024)是初始底层数组容量，10*1024*1024才是硬性上限。后者必须明确设为足够值，否则仍会触发错误。
- 不要只改第一个参数（容量），不设第二个（上限），无效
- 上限设得过大（如
int(^uint(0)>>1)）可能引发OOM，尤其在并发读多文件时 - 如果确定每行不会超几MB，设到
2*1024*1024比盲目设100MB更稳妥
用bufio.Reader.ReadString('\n')替代Scanner可完全规避token长度限制
当文件行长度不可控、或需自定义分隔符（如\r\n或\x00）时，Scanner不够灵活。Reader.ReadString没有内置长度限制，它只按需增长切片，且返回的字符串不包含分隔符，语义更清晰。
立即学习“go语言免费学习笔记（深入）”；
典型用法：
reader := bufio.NewReader(file)
for {
line, err := reader.ReadString('\n')
if err == io.EOF {
if len(line) > 0 {
// 处理最后一行（无换行符结尾的情况）
process(line)
}
break
}
if err != nil {
log.Fatal(err)
}
process(strings.TrimRight(line, "\r\n"))
}
-
ReadString返回的line包含\n，需用strings.TrimRight清理 - 务必检查
err == io.EOF后line是否非空——这是遗漏最后一行的高发点 - 比
Scanner略低效（少一层缓存抽象），但可控性强，适合解析协议文本或CSV流
逐块读取（Reader.Read）适合二进制或超大纯文本，但需手动处理边界
当文件达GB级、且无需按行处理（例如提取固定长度记录、校验哈希、流式解密），直接用Reader.Read最快。它绕过所有行解析逻辑，吞吐接近系统IO极限。
关键点在于：分块读取时，换行符可能被切在两块中间，必须保留末尾不完整片段并拼接下一块。
buf := make([]byte, 32*1024)
var leftover []byte
for {
n, err := reader.Read(buf)
if n == 0 && err == io.EOF {
break
}
if err != nil && err != io.EOF {
log.Fatal(err)
}
data := append(leftover, buf[:n]...)
lines := bytes.Split(data, []byte("\n"))
leftover = lines[len(lines)-1] // 保留最后一段（可能不完整）
for _, line := range lines[:len(lines)-1] {
process(line)
}
}
// 循环结束后处理剩余leftover（可能是最后一行，也可能为空）
if len(leftover) > 0 {
process(leftover)
}
- 每次
Read返回真实读取字节数n，不能直接用整个buf -
leftover机制是核心，漏掉会导致跨块换行符丢失 - 若业务允许，把
buf大小设为4K~64K之间，平衡内存与系统调用次数
性能差异主要来自缓冲区大小和内存分配策略，而非Scanner本身
很多人以为Scanner“慢”，其实瓶颈通常不在它，而在默认64KB缓冲太小导致频繁重分配，或未复用Scanner实例。
- 用
scanner.Scan()前，先scanner.Buffer(...)预设合理容量上限 - 避免在循环里反复
new Scanner，应复用同一实例 - 对纯ASCII日志，
Scanner和ReadString性能相差不到10%；但对含大量UTF-8多字节字符的文本，Scanner的SplitFunc自定义开销会上升 - 真正拖慢速度的往往是
process()里的操作（如正则匹配、JSON解析），而不是读取层
实际压测中，只要缓冲区设置得当，三者吞吐量差距远小于磁盘IO波动。优先保证逻辑正确和内存安全，再谈微优化。
