17370845950

bufio.Scanner 读取日志丢行或卡住，主因是默认缓冲区仅64KB且不扩容，超长行（如大JSON）触发“token too long”panic；需调用scanner.Buffer()设足够上限（如10MB），严格检查scanner.Err()，并避免ScanWords等非行切分；遇BOM、多行日志、文件轮转、编码异常等场景应改用bufio.Reader。

为什么 bufio.Scanner 读取日志文件会丢行或卡住

常见现象是程序只读到前几行就退出，或遇到长日志行（比如带超长 JSON 的 access log）直接 panic：scanner: token too long。根本原因是 bufio.Scanner 默认缓冲区只有 64KB，且不自动扩容；它设计目标是安全、流式解析短文本，不是处理任意长度日志行。

• 默认最大令牌长度为 bufio.MaxScanTokenSize（65536 字节），超出即报错
• 遇到空行、\r\n 混用、BOM 头时，Scan() 可能提前终止迭代
• 未显式检查 Err() 就跳出循环，会忽略 I/O 错误（如文件被轮转、权限变化）

如何安全地用 bufio.Scanner 读取生产日志文件

必须重设缓冲区并严格校验错误。下面是最小可行配置：

file, _ := os.Open("/var/log/app.log")
defer file.Close()

scanner := bufio.NewScanner(file)
// 必须在 Scan() 调用前设置
scanner.Buffer(make([]byte, 4096), 10*1024*1024) // 初始 4KB，上限 10MB
scanner.Split(bufio.ScanLines)

for scanner.Scan() {
    line := scanner.Text()
    // 处理单行日志，例如解析时间戳、提取 level
}
if err := scanner.Err(); err != nil {
    // 这里必须处理：可能是 EOF（正常），也可能是 read: connection reset（异常）
    log.Printf("scan error: %v", err)
}

• scanner.Buffer() 第二个参数是硬上限，设太小会 panic，设太大浪费内存；10MB 覆盖绝大多数日志行（含嵌套 JSON）
• 避免用 bufio.ScanWords 或自定义 split，日志行边界就是换行符，用 bufio.ScanLines 最稳
• 不要在循环内调用 scanner.Bytes() 后再 scanner.Text()，两者返回的底层切片可能失效

什么时候该放弃 bufio.Scanner 改用 bufio.Reader

当需要精确控制读取行为时——比如跳过 BOM、处理不规范换行、或边读边解压（.log.gz）、或需复用缓冲区做多次 peek ——bufio.Scanner 的封装反而碍事。

• 日志文件由其他进程实时追加，且你需检测文件是否被 logrotate 重命名：这时得用 os.Stat() 对比 inode，Scanner 无法感知
• 要支持从指定偏移量恢复读取（断点续读），Reader.ReadSlice('\n') 比 Scanner 更可控
• 日志行含二进制垃圾数据（如截断的 protobuf），Scanner 遇到非法 UTF-8 会静默失败，而 Reader 可配合 bytes.IndexByte() 手动找换行符

真实场景中容易被忽略的三个细节

日志处理不是“打开→读→关”这么简单。以下三点不处理，上线后必出问题：

• 文件可能被 logrotate rename 或 delete，os.Open() 成功不代表后续 Read() 一定成功；需监听 inotify 或定期 os.Stat()
• 多行日志（如 Java 异常堆栈）不会自动合并，Scanner 每次只吐一行，需自己缓存并判断是否属于上一条（例如匹配 ^\t+at 或 ^Caused by:）
• 时区与编码：Linux 系统日志默认是本地时区 + UTF-8，但某些嵌入式设备日志可能是 ISO-8859-1，scanner.Text() 不做编码转换，乱码只能靠上游统一