bufio.scanner 无法可靠切分含嵌套换行的日志，应改用 bufio.newreader 手动识别 json 边界或使用 journalctl -o json-seq 格式配合自定义 split 函数；解析 syslog 需补年份并位运算分离 pri；json.decoder 要按错误类型分支处理；避免正则、复用对象提升性能。
如何用 bufio.Scanner 流式切分日志行而不丢数据
直接用 bufio.Scanner 读取日志文件时，默认以换行符切分，但某些系统日志（如 journalctl -o json 输出）可能含嵌套换行的 message 字段，导致单条 JSON 被错误截断。这不是 Scanner 的 bug，而是它设计上不保证“按逻辑记录”切分。
解决办法是改用 bufio.NewReader + 手动查找完整 JSON 边界，或预处理日志输出格式。若必须用 Scanner，需确保源头日志已用 -o short-iso 或 -o json-seq（RFC 7464）格式——后者每条记录以 0x1E 开头，可用 Scanner.Split 自定义分割函数识别：
func splitJSONSeq(data []byte, atEOF bool) (advance int, token []byte, err error) {
if atEOF && len(data) == 0 {
return 0, nil, nil
}
if i := bytes.IndexByte(data, 0x1E); i >= 0 {
return i + 1, data[i+1 : len(data)], nil
}
if atEOF {
return len(data), data, nil
}
return 0, nil, nil
}
注意：自定义 Split 函数必须严格匹配实际分隔符，否则会卡死或漏读。
解析带时间戳和优先级字段的 syslog 格式字符串
典型 syslog 格式如 Aug 12 14:32:11 host app[1234]: hello world，其中 是 PRI 值（facility × 8 + severity），Aug 12 14:32:11 是无年份时间，host 和 app[1234] 是标识字段。Go 标准库没有开箱即用的 syslog 解析器，得手动拆解。
关键点在于时间解析——time.Parse 不支持无年份的 Jan 02 15:04:05 格式，需补上年份再解析；PRI 值需位运算分离：
-
priority & 0x07得 severity（0=emerg, 7=debug） -
priority >> 3得 facility（1=user, 16=local0 等）
示例片段：
const syslogFormat = "Jan 02 15:04:05" t, _ := time.Parse(syslogFormat, "Aug 12 14:32:11") // 补年份：取当前年，若日志时间跨年则需额外判断 t = t.AddDate(time.Now().Year()-1900, 0, 0)
注意：不同 syslog 实现（rsyslog vs systemd-journald）对空格、方括号、时区处理不一致，建议先用正则提取字段再解析，而非依赖固定索引。
用 json.Decoder 处理流式 JSON 日志时的 panic 风险
当日志源为 journalctl -o json 时，每行是独立 JSON 对象，但偶尔会出现空行、注释行或临时网络中断导致的半截 JSON。直接对 os.Stdin 或文件句柄调用 json.NewDecoder(r).Decode(&v) 会因无效输入 panic。
必须显式检查错误类型：
-
io.EOF正常结束 -
io.ErrUnexpectedEOF表示 JSON 不完整，应跳过该行或记录警告 -
json.SyntaxError表示格式错误，可打印出错位置（err.Offset）辅助排查
别用 decoder.More() 判断——它只对 JSON 数组有效，对多行 JSON 对象无效。正确做法是循环调用 Decode 并按错误类型分支处理。
性能瓶颈常在正则匹配和重复内存分配
如果日志格式不统一（比如混用 syslog 和 JSON），有人倾向用正则全量匹配字段。但 regexp.MustCompile 编译成本高，且每次 FindStringSubmatch 都分配新字节切片，GC 压力大。
更轻量的做法是用 strings.Index + strings.TrimSpace 定位关键分隔符（如冒号、方括号），再用 strconv.ParseInt 直接转换数字字段。对固定结构日志，手写解析比正则快 3–5 倍。
另外，避免在循环内创建新 struct 实例——复用一个实例并重置字段，或用对象池（sync.Pool）管理解析结果，尤其当日志吞吐量超 10k 条/秒时差异明显。
真正难的不是解析语法，而是日志源本身的不稳定性：同一服务可能在不同版本输出不同格式，或突然插入调试日志打乱字段顺序。上线前务必用真实日志样本做模糊测试，而不是只跑几个理想 case。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
