bufio.Scanner 读超大日志文件会 panic 或丢行，因其默认缓冲区仅 64KB，遇超长行触发 ErrTooLong 后静默终止扫描；需在 Scan() 循环后检查 scanner.Err()，并用 scanner.Buffer() 手动扩容缓冲区。
为什么 bufio.Scanner 读超大日志文件会 panic 或丢行
因为默认的 bufio.Scanner 缓冲区只有 64KB，遇到单行超长日志（比如带完整堆栈、嵌套 JSON 的错误行）直接触发 scanner.ErrTooLong，然后停止扫描——不是跳过，是彻底终止。更隐蔽的是，它不会报错退出，而是静默失败，后续 scanner.Scan() 返回 false，你若没检查 scanner.Err()，就以为文件读完了。
- 必须在调用
scanner.Scan()循环结束后，立即检查scanner.Err()是否非 nil - 用
scanner.Buffer(make([]byte, 4096), 1 手动扩容缓冲区上限到 1MB（第二个参数是最大容量） - 别设太大（比如 100MB），内存浪费且可能触发 GC 压力；1–2MB 对多数日志足够
- 如果日志真有持续超长行（如 base64 blob），考虑改用
bufio.Reader.ReadLine()自己拼接
用 bufio.Scanner 还是 bufio.Reader 读日志更稳
看日志格式是否“每行语义完整”。Nginx、Syslog、Go 标准日志这类结构化行日志，bufio.Scanner 简洁安全；但若日志本身含换行符（如 log.Printf("%+v", err) 输出的多行 struct），Scanner 会按物理换行切分，破坏逻辑完整性。
-
Scanner：适合纯文本行日志，开箱即用，但依赖ScanLines分隔逻辑，无法处理跨行内容 -
Reader.ReadLine()：返回[]byte和isPrefix，可手动累积未完成行，适合不规则日志 -
Reader.ReadBytes('\n')：比ReadLine多一次内存拷贝，但语义更直白；注意返回的 byte slice 包含\n，需bytes.TrimRight() - 性能上三者差异不大，瓶颈通常在磁盘 I/O，而非解析逻辑
Scanner.Split 自定义分隔符能解决什么问题
默认 ScanLines 按 \n 或 \r\n 切分，但有些日志用 |、\x00 甚至时间戳开头作为记录边界。这时要重写分隔逻辑，否则一行里多个 \n 就被拆碎。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 实现一个
SplitFunc，输入[]byte，输出advance（消费多少字节）、token（提取出的记录）、err - 例如按空行分割 HTTP 响应日志：
bytes.Index(b, []byte("\n\n"))找双换行 - 注意：自定义
Split后，scanner.Buffer()仍生效，但最大行长度判断逻辑由你控制，务必避免无限循环 - 别在
Split里做耗时操作（如正则匹配整块 buffer），会卡住整个扫描流程
内存占用和 GC 压力怎么悄悄变高
Scanner 内部 buffer 是复用的，但每次 scanner.Text() 返回的 string 会触发底层 unsafe.String() 转换，如果直接存起来（比如塞进 map 或 slice），等于把整个 buffer 的生命周期延长到引用消失——哪怕你只取了前 10 个字符，GC 也得等整块 buffer 被释放。
立即学习“go语言免费学习笔记（深入）”；
- 高频场景下，优先用
scanner.Bytes()，再string(b[:n])按需转局部字符串 - 避免在循环里无节制 append 到全局 slice：
lines = append(lines, scanner.Text())→ 改为lines = append(lines, string(scanner.Bytes()))并确保后续不长期持有 - 用
runtime.ReadMemStats对比前后Alloc和TotalAlloc，确认是否因字符串逃逸导致堆增长 - 日志行数超千万级时，考虑流式处理 + 限速（
time.Sleep）或分批（for i := 0; i ）
真正麻烦的不是读得慢，是读着读着 OOM 或 STW 时间飙升——那八成是字符串没管住，buffer 被意外钉在堆上了。
