go的bufio.scanner默认64kb缓冲区易因超长行报错，应按需调大至1–2mb；需保留多行时须深拷贝scanner.text()结果；务必及时关闭文件并清空缓冲区以防fd和内存泄漏。
Scanner默认缓冲区太小导致大文件读取失败
Go 的 bufio.Scanner 默认缓冲区只有 64KB，遇到超长行（比如日志中带大段 base64、JSON 或 minified HTML）会直接报 scanner: token too long 错误，不是文件太大，而是某一行太长撑爆了缓冲区。
实操建议：
- 用
scanner.Buffer主动扩大缓冲区，例如支持最长 1MB 的行：scanner := bufio.NewScanner(file) scanner.Buffer(make([]byte, 64*1024), 1024*1024)
- 别无脑设成
math.MaxInt32—— 这会让 Scanner 尝试分配数 GB 内存，一旦遇到畸形输入（如缺失换行的超大块），程序直接 OOM - 如果业务确定不会出现超长行，但文件本身几十 GB，缓冲区扩到 1–2MB 通常够用，兼顾安全与性能
ScanLines比ReadString('\n')更省内存但不可逆
Scanner.Scan() 底层调用的是 ScanLines 分割函数，它复用内部缓冲区，每次只拷贝换行符前的字节；而 bufio.Reader.ReadString('\n') 每次都 new 一个新字符串，GC 压力明显更高。
但注意：Scanner.Text() 返回的字符串底层指向 Scanner 自己的缓冲区，下一次 Scan() 就会覆盖——如果你把 scanner.Text() 结果塞进切片或 map 却没深拷贝，最后全变成最后一行的内容。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 需要保留多行内容时，显式拷贝：
line := strings.TrimSpace(scanner.Text()) lines = append(lines, line) // strings.TrimSpace 已触发拷贝
- 纯流式处理（如解析、过滤、计数）直接用
scanner.Text()安全，不存引用 - 若需原始字节（避免 UTF-8 解码开销），改用
scanner.Bytes()，同样要注意复用问题
按行读取时 bufio.Reader.ReadBytes('\n') 更可控
当 Scanner 的自动缓冲管理让你不放心（比如要精确控制内存上限、或需处理不以 \n 结尾的末行），bufio.Reader 的 ReadBytes 或 ReadLine 是更底层、更透明的选择。
ReadBytes 会包含换行符，ReadLine 不包含但可能返回部分数据（遇到缓冲区满且无换行时），需自行拼接 —— 大多数场景 ReadBytes 更直觉。
实操建议：
- 初始化 reader 时也记得设缓冲区：
reader := bufio.NewReaderSize(file, 1024*1024)
-
ReadBytes('\n')返回[]byte，如果后续要 string 操作，用string(bytes)而非string(bytes[:])（后者和 Scanner 一样危险） - 文件末尾无换行符时，
ReadBytes会返回剩余内容 +io.EOF，需检查err == io.EOF || err == nil来收尾
逐行处理大文件必须关闭文件并及时释放引用
很多人只记得 defer file.Close()，却忽略：只要 scanner 或 reader 还活着，底层 *os.File 就无法被 GC 回收，尤其在长生命周期对象（如 HTTP handler、全局 worker）里反复打开大文件，fd 泄漏比内存泄漏来得更快。
更隐蔽的问题是：把 scanner 存在 struct 字段里，又没清空其内部 buf 字段，会导致大缓冲区长期驻留堆上。
实操建议：
- 用完立即
file.Close()，不要依赖 defer（defer 在函数退出才执行，而函数可能很久才退） - 如果必须复用 scanner，每次用完手动清空：
scanner = bufio.NewScanner(file) // 重建更安全 // 或重置缓冲区： scanner.Buffer(make([]byte, 0, 64*1024), 1024*1024)
- 监控 fd 数量：
lsof -p $(pidof yourapp)，发现持续增长就是没关干净
