go 标准库无 log.parse 函数，实时流解析需手动提取字段；应预编译正则、加超时控制、标记解析失败日志；时间解析需按概率尝试多种格式并传入明确 location；bufio.scanner 丢行因 eof 无换行符，需手动补读；规则应抽象为独立函数并热加载。
为什么 log.Parse 不能直接用在实时流上
因为 Go 标准库没有 log.Parse 这个函数——这是最常见的误搜起点。真实场景里，你拿到的是原始日志行（string），不是结构化对象，得自己切、转、验。别指望 log.Logger 能反向解析，它只负责输出。
实时流要求低延迟、高吞吐，用 strings.Fields 或正则全量匹配每一行，性能会掉得明显；而跳过格式校验直接 json.Unmarshal，又容易因单条脏数据导致整个 goroutine panic 停摆。
- 优先用预编译的
regexp.Regexp提取关键字段（如时间戳、level、message），避免每次regexp.Compile - 对每条日志加超时控制：用
context.WithTimeout包裹解析逻辑，单条处理超过 5ms 就丢弃，保整体水位 - 错误日志本身也要进检测流——比如解析失败的行，应打上
parse_error标签，而不是被静默吞掉
如何让 time.Parse 不在时区和格式上反复翻车
日志时间戳五花八门："2024-05-21T14:23:11Z"、"May 21 14:23:11"、甚至带毫秒的 "2024-05-21 14:23:11.123"。硬写多个 time.Parse 分支容易漏，但全用 time.ParseInLocation + time.UTC 又可能把本地时区日志错当成 UTC。
真正稳的做法是：先用正则捕获时间字符串，再按常见格式列表逐个试，命中即止。别怕循环，10 次以内 time.Parse 开销远小于一次 GC 压力。
立即学习“go语言免费学习笔记（深入）”；
- 格式列表按匹配概率降序排，比如
time.RFC3339放最前，"Jan _2 15:04:05"放后面 - 始终传入明确的
*time.Location，不要依赖time.Local——容器环境里它可能是 UTC，也可能是空 - 解析失败时记录原始字符串和尝试过的格式，方便后续补规则，别只打 “parse failed”
bufio.Scanner 扫日志文件时为啥总丢最后一行
因为默认 ScanLines 遇到 EOF 且末尾无换行符时，会把缓冲区里没结束的那行直接丢弃。线上日志文件正在被 tail -f 写入，最后一行大概率没 \n，这行就没了。
这不是 bug，是设计使然。想收全，就得关掉默认行为，改用 scanner.Split(bufio.ScanBytes) 自己攒行，或者更简单：在扫描完后手动检查 scanner.Err() 是否为 io.EOF，再读一次 scanner.Bytes()。
- 用
scanner.Buffer扩大缓冲区（默认 64KB），避免长日志行触发ErrTooLong - 别在
for scanner.Scan()里做耗时操作（如网络请求），用 channel 把scanner.Text()推给 worker goroutine - 文件轮转（logrotate）时，
os.Open的 fd 会被回收，但scanner不知道——需监听inotify或定期检查os.Stat().Size是否归零
异常检测规则怎么避免写成“if 大杂烩”
用 if/else 堆条件判断，初期快，后期维护时连自己都看不懂为什么某条告警没触发。核心问题是：规则和日志结构耦合太死，新增一个字段就得改七八处。
可行解是把规则抽象成独立函数，输入是统一的 map[string]string（字段已从原始日志提取好），输出是 bool 和 string（触发原因）。所有规则注册到一个 map 里，热加载只需替换这个 map，不用重启进程。
- 规则函数名要带业务语义，比如
isHighLatencyError，而不是rule3 - 避免在规则里调用外部服务——超时或失败会导致整条日志卡住，必须用带 fallback 的本地缓存查维度
- 每条规则配一个
sample_rate字段，高频日志（如 access log）可设 0.1，低频关键日志（如 payment error）设 1.0
最麻烦的从来不是写检测逻辑，而是确认哪条日志该进哪个规则分支——字段提取不准，后面全白搭。宁可多花半小时校验正则，也别省这一步。
