默认 bufio.Scanner 缓冲区上限为 64KB，单行超长即返回 bufio.ErrTooLong；需显式调用 scanner.Buffer(make([]byte, 64*1024), 1<<20) 安全扩容。
为什么默认 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 + 正确打开方式。
立即学习“go语言免费学习笔记（深入）”；
- 永远用
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 转换开销
最常被忽略的一点：超长行问题本质不是 Go 的限制，而是数据契约缺失。上线前最好加个预检：抽样统计文件中第 99 分位行长度，再决定用 Scanner 还是 Reader，以及 buffer 设多大。
