os.readfile读大日志文件会卡死或oom，因其一次性将整个文件加载进内存，触发gc压力或runtime: out of memory；应改用bufio.scanner逐行流式读取，并显式设置缓冲区上限（如scanner.buffer(make([]byte,4096),1。
为什么 os.ReadFile 读大日志文件会卡死或 OOM
因为 os.ReadFile 会把整个文件一次性加载进内存，几百 MB 的日志直接触发 GC 压力甚至 runtime: out of memory。它不支持流式处理，也没法中断或进度反馈。真实场景里你根本不需要“全量读完”，而是要“边读边解析、过滤、聚合”。
- 日志文件通常为文本行格式，
bufio.Scanner是更自然的选择 - 若单行超长（如带巨量堆栈或 base64 日志），默认缓冲区会 panic，必须提前调用
scanner.Buffer - 避免用
strings.Split(string(b), "\n")——string(b)不拷贝底层数组，后续切片仍持有整块缓冲区引用
用 bufio.Scanner 逐行读取并控制内存
这是最常用也最稳妥的日志读取方式，关键在缓冲区设置和数据生命周期管理。
- 初始化时显式设缓冲区上限：
scanner.Buffer(make([]byte, 4096), 1（最小 4KB，最大 1MB） - 优先用
scanner.Text()而非scanner.Bytes()，前者已做深拷贝，不会意外 hold 住整块缓冲区 - 每行处理完立即丢弃引用；若需暂存，用
append([]byte(nil), line...)显式拷贝 - 不要把
scanner.Text()结果直接塞进全局 map 或 long-lived slice —— 它只是 string，但底层可能仍连着 scanner 的 buffer
并发处理日志行而非并发读文件
对单个日志文件开多个 goroutine 去读不同 offset，几乎总是更慢——磁盘寻道代价远高于 CPU 解析开销。真正该并发的是“解析后动作”。
- 用一个 goroutine 顺序读取（
bufio.Scanner），通过 channel 向 worker pool 推送每行内容 - worker 数量建议设为
runtime.NumCPU()或略高（如 ×1.5），避免过度调度 - 每个 worker 处理完一行后立刻返回，不累积中间状态；若需聚合，用 sync.Map 或预分配的 map + mutex 控制写竞争
- 注意 channel 缓冲区大小：太小导致 reader 阻塞，太大则内存堆积；常见设为 128～1024
什么时候该换 mmap 或自定义 Reader
绝大多数日志分析场景不需要 mmap。它只在极少数条件下带来收益：只读、文件稳定、需随机跳转（比如按时间戳二分查找某段日志）。
- 用
github.com/edsrzf/mmap-go替代原生 mmap 封装，避免 Windows 兼容性坑 - mmap 后仍要自己处理换页边界、文件截断、以及
unsafe.Slice的越界风险 - 若日志是结构化格式（如 JSON 行、Protobuf），且需反复随机访问字段，可考虑 mmap + 自定义 parser
- 日常运维类日志扫描（grep、统计、告警匹配），
bufio.Scanner+ 正则缓存 + worker pool 已足够快
scanner.Text() 出来，经过正则匹配、JSON 解析、再存进 map，只要其中任一环节没切断对原始字节的隐式依赖，整块 1MB 缓冲区就一直无法被 GC 回收。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
