log/scanner比bufio.Scanner更可靠，能正确处理跨行日志；需预编译正则、流式读取大文件、并发聚合时避免map竞态。
日志格式不统一时，log/scanner 比 bufio.Scanner 更可靠
很多日志文件混用空格、制表符、JSON 行、带时间戳的非结构化文本，直接用 bufio.Scanner 按行切分容易在换行符位置出错（比如堆栈跟踪跨多行）。Go 标准库没有内置日志解析器，但 log/scanner（第三方轻量包，非标准库）专为日志行边界识别设计，能自动跳过不完整行、合并续行。
- 安装：
go get github.com/mozillazg/go-log-scanner - 关键行为：它把
"2024-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 默认非并发安全。
立即学习“go语言免费学习笔记（深入）”；
- 简单方案：用
sync.Map，但只适合读多写少；频繁写入时性能不如sync.Mutex+ 普通 map - 更优解：每个 goroutine 维护本地
map[string]int，解析完再用sync.Mutex合并到全局结果 - 易忽略点：聚合 key 若含动态内容（如 IP、URL 路径），需做脱敏或截断，否则 map 可能无限膨胀
