直接用 bufio.Scanner 分块并发会丢行或错位，因其默认64KB缓冲区预读导致切点落在行中、无法回退已读字节，须向前找'\n'对齐行首，并处理末尾不完整行及分片间拼接；自定义SplitFunc需支持状态回溯与负advance，缓冲区应≥最长记录长度，goroutine间须避免共享底层数组。
为什么直接用 bufio.Scanner 分块并发会丢行或错位
因为 bufio.Scanner 内部自带缓冲和预读逻辑，默认 64KB 缓冲区会提前把下一块数据拉进来，但你手动用 file.Seek() 切分后，每个 Scanner 都从任意字节位置开始读——如果切点落在某行中间，前半截被第一个 Scanner 缓存却没触发 Scan()，后半截被第二个当成新行处理，整行就断了。更麻烦的是，Scanner 没有“回退已读字节”的能力，无法对齐到行首。
常见错误现象包括：搜索关键词命中数明显偏低、同一行在多个 goroutine 中被重复匹配、某些长日志行完全消失。
- 必须先用
file.Seek()定位到粗略边界，再向前找最近的'\n'（用io.ReadBytes('\n')往回扫），然后file.Seek(1, io.SeekCurrent)跳过该换行符，确保下一行完整开头 - 若分片末尾不以
'\n'结尾（即最后一行没换行），需额外读取下一分片开头若干字节（长度 ≥ 最长可能行），拼接到当前块末尾再处理 - 别复用同一个
buf给多个Scanner——它们共享底层数组，后续Read()会覆盖前面内容
如何让每个分片起点对齐到完整语义单元
按字节切只是第一步，真正要对齐的是数据结构边界。比如日志按 "[INFO]" 开头切、JSON 按 { 和 } 深度归零处切、XML 按 <tag></tag> 和 成对闭合切。这些都不能靠简单字符串查找完成，必须带状态回溯。
例如识别以 "[INFO]" 开头的新条目：SplitFunc 不能只查当前位置是否匹配，而要往前扫描，找到上一个 "[INFO]" 的起始位置，把那一段作为 token 返回；否则遇到 "[WARN][INFO]..." 就会错切。
立即学习“go语言免费学习笔记（深入）”；
- 用
bufio.Scanner时传入自定义SplitFunc，返回的advance必须是负值（表示回退），且不能超过当前缓冲区范围 - 缓冲区容量至少设为最长可能记录长度（如含 base64 的 JSON 日志，建议 ≥ 2MB），否则
Scanner.Err() == bufio.ErrTooLong - 若分隔符是多字节（如
"---\n"），SplitFunc内部要用滑动窗口比对，不能只查单个字符
并发读取时如何避免数据错乱和内存爆炸
起多个 goroutine 各自打开文件句柄并 Seek 到不同偏移，看似隔离，但若共用同一片 []byte 缓冲区，或通过 channel 发送未复制的切片，就会出现所有 goroutine 处理的 []byte 内容完全一样——因为底层数组被反复覆盖。
典型错误写法：ch ，这里发送的是指针，不是副本。
- 发送前必须显式复制：
ch 或 <code>ch （Go 1.20+） -
channel缓冲区大小设为make(chan []byte, 8)，既防阻塞也防堆积；别用无缓冲（worker 稍慢就卡死读协程），也别设太大（如 1000）导致未消费数据吃光内存 - 若处理逻辑含网络请求或 DB 写入，务必加
context.WithTimeout(ctx, 30*time.Second)，防止某块因外部依赖卡住拖垮整个 pipeline
strings.Index 还是 bytes.Index？什么时候该换方案
对纯 ASCII 关键词（如 "ERROR"、"GET "），bytes.Index(scanner.Bytes(), []byte("ERROR")) 比 strings.Contains(scanner.Text(), "ERROR") 快 2–3 倍——跳过了 UTF-8 解码和 slicebytetostring 分配。
但如果你要匹配中文或 emoji，bytes.Index 仍可用（UTF-8 编码下字节匹配等价于字符匹配），只是得确保模式串也是 []byte 类型；千万别把 string 强转成 []rune 再喂给 KMP，那会彻底错位。
- 单关键词、逐行查：优先用
bytes.Index+scanner.Bytes() - 多关键词（>5 个）同时查：别循环调用
strings.Index，改用ahocorasick库或手写 AC 自动机，复杂度从 O(n×m) 降到 O(n + 输出) - 超长行（>1MB）中搜短关键词：先做长度预检
if len(line) > 1024*1024 { continue }，避免strings.Contains在巨大字符串上反复扫描
实际落地时，最易被忽略的是分片边界的双向对齐：既要向前找上一个完整单元起始，也要向后确认本单元是否闭合（如 JSON 深度是否归零、XML 标签是否成对）。这个状态机逻辑没法偷懒，必须手写，而且每种格式都要单独适配。
