Golang怎么处理大文件逐行读取_Golang如何用bufio.Scanner按行高效读取超大文件【技巧】-Golang-PHP中文网

默认 bufio.scanner 缓冲区上限为 64kb，单行超长即返回 bufio.errtoolong；需显式调用 scanner.buffer(make([]byte, 64*1024), 1

golang怎么处理大文件逐行读取_golang如何用bufio.scanner按行高效读取超大文件【技巧】

为什么默认 `bufio.Scanner` 读大文件会 panic 或返回 `bufio.ErrTooLong`

因为它的缓冲区上限默认只有 64KB，遇到单行超长（比如日志里混了 base64、JSON blob、堆栈 trace）就直接失败，scanner.Scan() 返回 false，scanner.Err() 是 bufio.ErrTooLong —— 不是 EOF，也不是 I/O 错误，而是“我缓存装不下了”。你调 scanner.Text() 拿不到任何内容，也没法恢复继续读。

这不是 bug，是 Scanner 的设计取舍：优先保证“一行完整”，不自动扩容，也不提示预警
哪怕文件本身才几 MB，只要某一行超过 64KB（比如一个没换行的超长 URL 或嵌入式数据），就会触发
math.MaxInt32 不能当万能解——设太大等于放弃保护，恶意输入或异常数据可能拖垮服务内存

怎么安全扩大 `scanner.Buffer()` 上限（且不翻车）

必须显式调用 scanner.Buffer()，传两个参数：初始 buffer slice 和最大容量。只改第二个参数没用，第一个也得给够，否则 runtime 还是走默认 64KB。

推荐组合：scanner.Buffer(make([]byte, 64*1024), 1 → 初始 64KB，上限 1MB
如果业务确定不会出现 >1MB 单行（如标准 Nginx 日志、CSV），这个设置足够稳，GC 压力可控
不要写 scanner.Buffer(nil, 1 —— <code>nil 会让 Scanner 内部 fallback 到默认值，上限还是 64KB
注意：第二个参数不能超过 math.MaxInt32（约 2GB），但实际建议别超 4MB，再大就该换方案了

什么时候该果断放弃 `Scanner`，改用 `bufio.Reader.ReadString('\n')`

当你无法控制输入格式（比如解析第三方日志、用户上传文本、协议响应体），或者需要做行级长度校验、截断、告警时，Scanner 就太“刚”了。ReadString() 更底层、更可控，而且没有内置长度限制。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

ReadString() 边读边 append，实际长度只受可用内存约束，出错时返回 io.EOF 或具体 I/O error，不会突然中断流
它保留原始换行符（\r\n 或 \n），需手动 bytes.TrimRight(line, "\r\n")，但换来的是可预测行为
配合 io.LimitReader 可轻松实现“单行最多读 2MB，超长就丢弃并打 warn 日志”
性能上反而略优：绕过了 Scanner 内部状态机和 token 复制逻辑

真正高效读 GB 级文本的关键不是“选哪个函数”，而是 IO 模式

95% 的日志/ETL 场景只是顺序扫描，瓶颈不在解析逻辑，而在系统调用次数和内存分配频率。光调 Buffer() 不够，得配大 buffer + 正确打开方式。

永远用 os.Open()，禁用 ioutil.ReadFile() 或 os.ReadFile() —— 它们会把整个文件 load 到内存
给 bufio.Reader（或 Scanner 底层）配 1MB buffer：bufio.NewReaderSize(file, 1*1024*1024)，SSD/NVMe 下 syscall 次数能降 80%+
如果后续要解析 CSV/TSV，直接传这个大 buffer 的 Reader 给 encoding/csv.NewReader()，它内部已做优化，别自己再套一层 Scanner
别迷信“一行一处理”——若业务允许批处理（比如每 1000 行聚合一次），用 ReadSlice('\n') 手动攒 batch，减少 string 转换开销