安全读取大日志需流式处理：用 bufio.NewReaderSize 控制缓冲区，reader.ReadString 手动处理换行与 EOF，配合 fsnotify 监听轮转；解析需分层去引号、精准 time.Parse 时间戳；并发统计用分片 sync.Map 避免 panic；结构化日志（如 JSON）支持字段级查询，比文本正则更可靠高效。
直接用 strings.Contains 做日志关键词搜索，快但太糙；真要支撑线上分析，得从解析格式、并发控制、字段提取三块一起动，否则查着查着就 OOM 或漏数据。
怎么安全读取大日志文件不崩内存
别用 os.ReadFile 加载整文件——几十 MB 的 access.log 就可能吃光 RSS。必须流式处理。
- 用
bufio.NewReaderSize(file, 1024*1024)控制缓冲区，避免默认 4KB 太小导致系统调用频繁 - 超长行（如带堆栈的 error 日志）会卡死
bufio.Scanner，改用reader.ReadString('\n')并手动处理\r\n和 EOF 边界 - 每次读完一行后检查
err：若为io.EOF，正常退出；若为其他 I/O 错误（如磁盘拔出），需显式记录并中断 - 正在被
logrotate切割的文件，inode 可能已变，单靠Seek(io.SeekEnd)会读不到新内容——得配合fsnotify监听 WRITE 事件 +Stat()比对Ino
如何正确解析 Nginx/Apache access log 字段
空格分隔 ≠ 能直接 strings.Split。引号包裹的字段（如 "GET /api/v1/users HTTP/1.1"）会被切碎，必须分层处理。
- 先用
strings.FieldsFunc(line, func(r rune) bool { return r == ' ' })粗切，得到基础字段切片 - 再对第 6、7、9 等固定位置字段（依
log_format而定）调用strings.Trim(field, `"`)去引号 - 时间戳字段如
[10/Jul/2024:15:22:34 +0800]必须用time.Parse("[02/Jan/2006:15:04:05 -0700]", ts)，layout 错一位就全错 - 状态码和响应体大小字段可能是
-，解析前务必strings.TrimSpace并判断是否为空字符串
并发搜索多个日志文件时怎么不 panic
goroutine 一多，map[string]int 统计频次就会触发 fatal error: concurrent map writes，加锁也扛不住高写入压力。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 别用单个
sync.RWMutex包一层 map——每秒万级写入下锁竞争严重 - 改用分片策略：声明
[8]*sync.Map，key 的 hash 对 8 取模决定写入哪个分片 - 查询总数时遍历全部 8 个分片，用
Range累加，不阻塞写入 - 匹配结果收集用带缓冲通道（如
make(chan Match, 100)），消费端固定启 4–8 个 goroutine，避免句柄耗尽
为什么结构化日志比文本日志更适合搜索
不是“更高级”，而是绕不开的工程现实：grep 查 level=error 很快，但查 "status_code":503 且排除 "service":"healthz" 就必须依赖 JSON 解析能力。
- 用
zap或slog输出 JSON 日志，字段天然可索引，不用正则硬抠 - 采集端（如 Promtail）能自动提取
trace_id、method等字段，Loki 查询语法直接写{job="api"} | json | status_code == 503 - 如果自己解析，别用
json.Unmarshal全量解，对大日志用json.RawMessage按需解析关键字段，省 60%+ CPU - HTTP 中间件里注入
trace_id必须用自定义 context key（如type ctxKey string; const traceIDKey ctxKey = "trace_id"），否则不同库冲突导致字段丢失
真正卡住人的从来不是“怎么写一行搜索代码”，而是日志格式不一致、文件被轮转、并发写 map panic、trace_id 在 goroutine 里断掉——这些点漏一个，线上查问题就得多花半小时。
