bufio.Scanner 流式读取大日志需调大缓冲区、手动按 \n 切分、复用正则、单协程顺序统计，时间解析优先用 time.ParseInLocation + 预设 layout 或 dateparse 库。
如何用 bufio.Scanner 高效读取大日志文件而不爆内存
直接用 os.ReadFile 读取几 GB 的日志会 OOM，必须流式处理。bufio.Scanner 是最常用也最容易踩坑的选择：默认 64KB 缓冲区，遇到超长行（比如带大段 JSON 的访问日志）会直接报 scanner: token too long。
实操建议：
- 调大缓冲区：
scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)（第二参数是最大 token 长度，设为 10MB 覆盖绝大多数日志行） - 禁用行分割、手动按 \n 切分：避免因 \r\n 或不规范换行导致漏行，用
bytes.Split(buf, []byte("\n"))更可控 - 每处理完一批行（如 1000 行）主动
runtime.GC()—— 不是必需，但在长时间运行的分析工具中能缓解 GC 压力累积
用 time.Parse 解析常见日志时间格式的坑与绕过方案
nginx、access.log、systemd-journal 输出的时间格式五花八门：02/Jan/2006:15:04:05 -0700、2024-03-15T14:22:03.123Z、Mar 15 14:22:03。硬写多个 time.Parse 分支容易漏，且性能差。
推荐做法：
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 优先用
time.ParseInLocation+ 固定时区（如time.UTC），避免依赖本地时区引发错乱 - 对 nginx 类格式，直接用
"02/Jan/2006:15:04:05 -0700"；对 RFC3339，用time.RFC3339Nano—— 别自己拼 layout 字符串 - 实在无法预判格式时，用
github.com/araddon/dateparse库，它内部做了启发式匹配，比反复Parse快且鲁棒
正则提取字段时，regexp.Compile 必须复用，且注意命名捕获组性能差异
在循环中每次 regexp.Compile(`...`) 会导致 CPU 暴涨，尤其当日志量大时。Go 的 regexp 编译开销不小，而且编译后对象是线程安全的。
关键点：
- 把正则变量声明为包级变量或初始化一次的全局变量，例如：
var logRegex = regexp.MustCompile(`(?P<ip>\S+) - (?P<user>\S+) \[(?P<time>[^\]]+)\] "(?P<req>[^"]+)" (?P<code>\d+) (?P<size>\d+)`)</size> - 避免用
FindStringSubmatch+ 手动索引取值；改用FindStringSubmatchIndex+ 命名组索引，可读性高且不易错位 - 如果只关心某几个字段（如只统计状态码），用非捕获组
(?:...)替代冗余捕获，减少正则引擎开销
输出聚合结果时，map[string]int 不适合高频更新，改用 sync.Map 或预分配切片
分析过程中统计 IP 访问频次、URL 调用次数等，若直接用普通 map 并发写入会 panic。但盲目上 sync.Map 也不一定最优——它适用于读多写少，而日志分析通常是写密集场景。
更实际的策略：
- 单 goroutine 顺序处理日志行，用普通
map[string]int累计，最后再合并结果；这是最简单、最不容易出错的方式 - 真要并发处理（如按文件分片），每个 goroutine 用独立
map，结束时用for k, v := range subMap { totalMap[k] += v }合并 - 对固定维度统计（如 HTTP 状态码只有几十种），直接用
[]int{200: 1, 404: 1, ...}切片索引，比 map 快一个数量级
日志行解析本身不难，难的是在吞吐、内存、准确率之间做取舍；尤其是时间解析和正则，稍不注意就会让工具在真实环境里跑着跑着就慢下来或者挂掉。
