应使用 bufio.Scanner 流式逐行读取大日志文件，其默认 64KB 缓冲区可避免 OOM；超长行需调大 Buffer 限制；优先用 bytes 操作和 strings.Index/SplitN 精准提取字段，避免正则脆弱性和字符串重复拷贝。
如何用 bufio.Scanner 逐行读取大日志文件而不爆内存
Go 解析日志最怕一次性 os.ReadFile 加载整个文件——几 GB 的 access.log 直接 OOM。必须流式处理。bufio.Scanner 是标准库里最稳妥的选择，它默认缓冲区 64KB，能自动按行切分，且不会把整文件塞进内存。
注意：默认单行上限是 65536 字节，如果日志里有超长堆栈或 base64 字段，会报 scanner: token too long。这时得手动调大：
scanner := bufio.NewScanner(file) scanner.Buffer(make([]byte, 64*1024), 1024*1024) // max 1MB per line
- 别用
strings.Split(string(b), "\n")—— 转成字符串再切，等于又复制了一遍数据 - 避免在循环里反复
strings.TrimSpace()和strings.Fields()，能用bytes就别转string - 如果日志是 JSON 格式，直接用
json.Decoder配合bufio.Reader更稳，不依赖换行符
用正则还是 strings.Index 提取字段更可靠
正则看着方便，但线上日志格式稍一变动（比如多一个空格、少一个字段）就全挂；而 strings.Index + strings.SplitN 虽啰嗦，却能精准锚定固定分隔符（如 " " 或 "|"），失败时也容易定位哪一列缺失。
比如 Nginx 默认日志中提取状态码和响应时间：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
line := `192.168.1.1 - - [10/Jan/2024:12:34:56 +0000] "GET /api/v1/users HTTP/1.1" 200 1234 0.123 "Mozilla/..."`
// 错误示范：用正则匹配数字，可能把 IP 或 body size 也抓进来
// 正确做法：按引号和空格分层切
parts := strings.Split(line, `"`)
if len(parts) < 3 { return }
req := parts[1] // GET /api/v1/users HTTP/1.1
status := strings.Fields(parts[2])[0] // " 200 1234 0.123 " → 取第一个数字
- 正则只在格式高度自由（如混合日志、无固定分隔）时才考虑，且务必编译一次复用：
var re = regexp.MustCompile(`\s+(\d{3})\s+(\d+\.?\d*)\s+`)` -
strings.Index比strings.Contains多一步定位，但能避免误匹配（比如 “200” 出现在 URL 里） - 如果日志带时区或毫秒级时间戳，别用
time.Parse直接怼，先用strings.Trim去掉方括号再切
统计指标聚合该用 map[string]int64 还是 sync.Map
单 goroutine 处理日志时，map[string]int64 足够快且安全；但如果你开了多个 goroutine 并发解析不同文件片段，就必须上 sync.Map，否则会 panic：fatal error: concurrent map writes。
不过 sync.Map 对纯计数场景有点重——它为读多写少优化，而日志统计通常是“写多读少”。更轻量的做法是每个 goroutine 维护自己的局部 map，最后再合并：
type Stats struct {
StatusCount map[string]int64
TotalTime float64
}
// 每个 goroutine 返回自己的 Stats，主协程用 for-range 累加- 避免用
map[interface{}]interface{}存统计项——类型断言麻烦，还易出错 - 如果要按分钟聚合请求量，key 别拼字符串如
fmt.Sprintf("%s:%02d", date, hour)，用time.Truncate得到time.Time再转 Unix 时间戳当 key，更易比对 - 计数器别用
int，防止超 21 亿条日志溢出，统一用int64
如何让日志解析逻辑支持增量重跑和断点续传
线上日志每天滚动，不可能每次都从头扫。关键不是“怎么快”，而是“怎么不错漏”。最简单可靠的方式：记录已处理的文件偏移量（file.Seek）或行号，存到本地小文件或 etcd。
示例结构：
type Progress struct {
Filename string `json:"filename"`
Offset int64 `json:"offset"` // 下次从这个字节位置开始读
}
// 每处理完 1000 行，调用一次 saveProgress() 写入磁盘- 别依赖文件名判断是否处理过——
access.log.1可能被 logrotate 重命名，应以 inode + dev 为唯一标识 - 如果日志是追加写入（如 tail -f 场景），得用
os.Stat().Size()对比当前大小，防止读到半截的行 - 偏移量保存必须 fsync，否则进程崩溃时进度丢失；可用
os.O_SYNC打开进度文件
真正难的不是解析本身，而是怎么在日志格式微调、服务重启、文件轮转这些边界条件下，依然保证统计数字不重复、不遗漏——所有技巧都得围着这个转。
