直接用 bufio.Scanner 读日志易丢行或卡住，因其默认64KB缓冲区无法处理超长行（如堆栈、jsON），应改用 bufio.Reader 自定义缓冲区并配合 ReadString 或 ReadLine。
为什么直接用 bufio.Scanner 读日志文件容易丢行或卡住
日志文件常含超长行（如堆栈跟踪、json 嵌套字段），bufio.Scanner 默认缓冲区仅 64KB，遇到单行超过该长度会直接报 scanner: Token too long 并终止扫描。这不是 bug，是设计使然——它面向“行结构清晰”的文本，而非生产日志。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 改用
bufio.Reader+ReadString('n')或ReadLine()，自行控制缓冲区大小（如bufio.NewReaderSize(file, 1024*1024)） - 若需保留换行符且处理二进制安全日志（含 ），用
ReadLine()更稳妥，注意它不自动补回车符，需手动拼接 - 避免在循环中反复创建
Scanner实例——开销大，且无法复用底层Reader
如何用正则高效提取 nginx/go http 日志中的关键字段
别写一个巨长正则匹配整行。日志格式固定但字段可选（如 referer、user-agent 可能为空），硬匹配易因空格/引号嵌套失败。应分层提取：先切分基础段（时间、IP、方法），再对字段值单独解析。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对标准 Nginx
log_format，优先用strings.FieldsFunc(line, func(r rune) bool { return r == ' ' || r == '[' || r == ']' })粗切，再按位置取字段（比全量正则快 3–5 倍） - 真正需要正则时，预编译并复用：
var reIP = regexp.MustCompilePOSIX(`b(?:[0-9]{1,3}.){3}[0-9]{1,3}b`)；避免在循环里调用regexp.Compile - Go 自带
net/http/httputil不适用日志解析——它只处理内存中 *http.Request，无法反向从字符串还原结构
如何让日志分析支持实时 tail -f 且不漏数据
用 os.OpenFile 打开正在被追加的文件后，仅靠 Seek(0, io.SeekEnd) 不够。linux 下文件可能被 logrotate 切走，原 fd 仍指向旧 inode，新日志写入新文件，程序就卡死在 EOF。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
fsnotify监听目录，检测WRITE事件后重新stat文件，比对os.FileInfo.Sys().(*syscall.Stat_t).Ino判断是否 inode 变更 - 每次读到 EOF 后，sleep 100ms 再
Seek(0, io.SeekCurrent)检查文件大小是否增长——不要无脑重 open - 若用
tail -f类似逻辑，必须处理syscall.EINTR错误（信号中断读操作），否则 SIGUSR1 等信号会导致程序退出
结构化输出时，encoding/json 和 gob 怎么选
日志分析结果要存档或传给下游？别默认选 JSON。它可读，但 Go 结构体字段名默认全小写，导出需加 json:"field_name" tag；且浮点数精度、time.Time 格式（RFC3339 还是 unix 纳秒）都得显式控制。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 内部服务间传输或临时缓存，用
gob——零配置、速度快、保留 Go 类型（time.Time、map[string]Interface{}直接序列化） - 对外提供 API 或存入 ES，用
json.Marshal，但务必封装一层：type LogEntry Struct { timestamp time.Time `json:"@timestamp"` ... }，避免裸 struct 导出 - 千万避免用
fmt.Sprintf("%+v")生成“伪 JSON”——字段顺序不定、无转义、引号混乱，下游解析必崩
日志分析真正的难点不在解析语法，而在处理现实世界的不一致：rotated 文件句柄失效、日志行编码混杂（UTF-8 / GBK）、同一服务多进程写同一文件导致行撕裂。这些没法靠一个库解决，得在 Read 循环里埋足够多的 if err != nil 分支和日志上下文记录。