17370845950

log/scanner比bufio.Scanner更可靠，能正确处理跨行日志；需预编译正则、流式读取大文件、并发聚合时避免map竞态。

日志格式不统一时，log/scanner 比 bufio.Scanner 更可靠

很多日志文件混用空格、制表符、JSON 行、带时间戳的非结构化文本，直接用 bufio.Scanner 按行切分容易在换行符位置出错（比如堆栈跟踪跨多行）。Go 标准库没有内置日志解析器，但 log/scanner（第三方轻量包，非标准库）专为日志行边界识别设计，能自动跳过不完整行、合并续行。

• 安装：go get github.com/mozillazg/go-log-scanner
• 关键行为：它把 "2025-01-01T12:00:00Z ERROR failed to connect: dial timeout\n\tat db.go:42" 当作单条日志，而非两行
• 替代方案：自己写状态机识别 ^\d{4}-\d{2}-\d{2} 开头的行，但维护成本高

用 regexp.MustCompile 预编译正则，避免在循环里重复编译

分析每行日志时若用 regexp.Compile 动态生成正则对象，CPU 会明显抖动——尤其处理 GB 级日志时。必须提前编译好，复用同一实例。

// ✅ 正确：包级变量，启动时编译一次
var logLineRE = regexp.MustCompile(`^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) (\w+) (.+)$`)

// ❌ 错误：每次调用都重新编译
func parseLine(line string) (time.Time, string, string) {
    re := regexp.MustCompile(`...`) // 这里会成为性能瓶颈
    // ...
}

• 常见错误：把正则写在函数内且未加缓存，压测时 runtime.mallocgc 占比飙升
• 调试技巧：用 go tool pprof 查看 regexp.(*Regexp).doExecute 耗时占比
• 注意：如果日志格式多变（如 Nginx access log + Go

  

  std log 混合），需预编译多个 *regexp.Regexp 并按前缀快速路由

大日志文件别用 ioutil.ReadFile，改用 os.Open + bufio.Reader

ioutil.ReadFile（或 os.ReadFile）会把整个文件读进内存，1GB 日志直接触发 OOM。真实场景下必须流式处理。

• 典型错误：写个 lines := strings.Split(string(data), "\n")，看似简洁，实则危险
• 正确姿势：用 os.Open 打开文件，套一层 bufio.NewReader，再配合 log/scanner 或自定义 ReadLine
• 额外提醒：Windows 换行符 \r\n 在 Linux 环境下可能被截断，建议统一用 scanner.Text()（它自动处理换行符归一化）

输出聚合结果时，map[string]int 不适合高并发计数

如果工具支持多 goroutine 并发解析不同日志段（比如按文件分片），直接用普通 map[string]int 更新错误类型统计会 panic：Go 的 map 默认非并发安全。

• 简单方案：用 sync.Map，但只适合读多写少；频繁写入时性能不如 sync.Mutex + 普通 map
• 更优解：每个 goroutine 维护本地 map[string]int，解析完再用 sync.Mutex 合并到全局结果
• 易忽略点：聚合 key 若含动态内容（如 IP、URL 路径），需做脱敏或截断，否则 map 可能无限膨胀

实际跑通一个最小可行版本，核心就三件事：打开文件流、按行识别日志边界、用预编译正则提取字段。最难的不是语法，是日志样本里那些没文档说明的隐式格式——比如某服务在 ERROR 前多打了一个空格，或时间戳偶尔缺毫秒位。先拿 100 行真实日志手工对齐正则，比早早在代码里堆功能更重要。