因为 bufio.Scanner 默认最大缓冲区仅64KB，超长行触发 ErrTooLong 后扫描直接终止，后续内容全丢；必须显式调用 scanner.Buffer() 提升上限，或改用 bufio.Reader 以避免丢行。
为什么 bufio.Scanner 默认会丢弃超长行？
因为 bufio.Scanner 默认最大缓冲区只有 64KB（bufio.MaxScanTokenSize），一旦某行字符数超过该限制，Scan() 就会返回 false，且 Err() 返回 bufio.ErrTooLong —— 这不是错误被忽略，而是扫描直接终止，后续内容全丢。
实际检索大文件时，尤其日志或导出数据中存在超长 JSON 行、base64 字段或未换行的二进制 dump，极易触发此问题，导致匹配漏掉关键行。
- 必须显式调用
Scanner.Buffer()提升缓冲区上限，例如：scanner.Buffer(make([]byte, 0, 10*1024*1024), 10*1024*1024)（10MB） - 缓冲区底层数组容量（第二个参数）不能超过
math.MaxInt32，但也不宜设为过大（如 100MB），否则内存占用陡增且无实际收益 - 若文件含真正无限长行（如缺失换行符的单行 GB 文件），仍可能失败；此时应改用
bufio.Reader+ 手动分块读取
如何安全地逐行扫描并做字符串模式匹配？
别直接在 Scan() 循环里对 scanner.Text() 做 strings.Contains() 或正则匹配——Text() 返回的是底层缓冲区的切片，下一次 Scan() 调用会复用同一块内存，导致前次结果被覆盖（尤其多 goroutine 或缓存引用时）。
- 每次匹配前先拷贝：
line := append([]byte(nil), scanner.Bytes()...)，再转string(line)或直接用bytes.Contains(line, []byte("pattern")) - 若用正则，务必预编译：
var re = regexp.MustCompile(`\bERROR\b`)，避免每次循环重复编译 - 注意
scanner.Bytes()比scanner.Text()少一次内存分配，对高频匹配更友好
遇到二进制文件或非 UTF-8 编码怎么办？
bufio.Scanner 本质是文本行扫描器，它按 \n（或指定分隔符）切分，不校验编码。如果文件含非法 UTF-8 字节（如 GBK 日志、部分 Windows 日志、混合编码导出），scanner.Text() 会把无效字节替换为 U+FFFD（），但 scanner.Bytes() 保留原始字节 —— 这才是做模式匹配的正确输入源。
立即学习“go语言免费学习笔记（深入）”；
- 所有字符串字面量匹配（如
"login failed"）必须转成[]byte，用bytes.Contains()或bytes.Index() - 避免使用
strings.ToXXX()等依赖 UTF-8 的函数处理scanner.Text()结果 - 若需按编码解码后再匹配（如 GBK），应放弃
Scanner，改用bufio.Reader配合golang.org/x/text/encoding逐块解码
性能瓶颈常卡在哪儿？
实测千万行级文件，90% 时间消耗不在匹配逻辑，而在系统调用和内存拷贝：每次 Scan() 触发一次 read() 系统调用（除非缓冲区已满），而默认 bufio.Scanner 底层 Reader 缓冲区仅 4KB，频繁进出内核态。
- 初始化时传入更大缓冲的
io.Reader：bufio.NewReaderSize(file, 1（1MB），再包给 <code>Scanner - 禁用自动换行识别（如只需按固定长度分块）：用
scanner.Split(bufio.ScanBytes)或自定义SplitFunc，但需自行处理边界 - 纯字节匹配场景下，
bytes.Index()比strings.Contains()快 2–3 倍，且无编码副作用
真正的大文件检索，往往不是“怎么写对”，而是“怎么不让 Scanner 自己拖垮性能”。缓冲区大小、字节 vs 字符、系统调用频率——这三个点没调好，再准的正则也白搭。
