bufio.Scanner不能天然支持按offset分片，因其内部预读缓冲区无回退机制，强行Seek会导致跨行断裂；安全分片需手动对齐行边界：Seek后向前找'\n'再跳过，末尾不完整行需拼接；超长行应改用ReadString或ReadBytes配合长度过滤；无换行符或需精确控制时应弃用Scanner改用Reader。
直接分块读取大文本文件时，bufio.Scanner 不能“天然支持”分片——它设计为单一流式处理，强行按 offset 切开会导致跨行断裂、内容错位、关键词匹配失败。真要分片，必须手动对齐行边界；若文件无换行（如二进制日志），就得换 io.ReadAt 或 file.Seek() 配固定块读。
为什么 Scanner 按 offset 分片会丢行
bufio.Scanner 内部有预读缓冲区（默认 64KB），且不提供回退机制。当你在第 9.9MB 处 file.Seek() 后新建一个 Scanner，它会从该位置开始读，但上一行的后半截可能还卡在前一个 Scanner 的 buffer 里没触发 Scan()，而新 Scanner 把后半截当新行开头——整行被撕成两半。
- 这不是 bug，是 Scanner 的前提假设：输入是连续、不可分割的流
- 所有“分片 Scanner”方案若没手动找
'\n'对齐起始位置，都存在此风险 - 尤其在日志分析中，跨分片的 JSON 行或 base64 字段会直接解析失败
如何安全地分片 + 按行处理
核心动作只有两个：Seek 到行首、拼接末尾不完整行。不能跳过任何一步。
- 分片起点：先
file.Seek(offset, io.SeekStart)，再用io.ReadBytes('\n')往前找最近的'\n'，然后file.Seek(1, io.SeekCurrent)跳过它，确保从下一行开头开始 - 分片终点：若最后一行没以
'\n'结尾（即文件末尾无换行符），需从下一偏移处继续读直到遇到'\n'，把这段拼到当前分片末尾再处理 - 别复用同一
[]byte缓冲区给多个 Scanner——每个分片应 new 独立bufio.Scanner，并配独立 buffer
超长行（>64KB）导致 scanner: token too long 怎么办
这个 panic 不是配置能绕过的硬限制。调大 scanner.Buffer() 只是权宜之计，设太大（比如 10MB）会在高并发分片场景下迅速吃光内存。
立即学习“go语言免费学习笔记（深入）”；
- 更稳的做法是切换到
bufio.NewReader(file).ReadString('\n')，自己控制每次读行为 - 加长度阈值过滤：
if len(line) > 1024*1024 { continue }，避免后续strings.Contains在 MB 级字符串上反复扫描 - 若必须保留超长行内容，用
reader.ReadBytes('\n')+ 手动拼接isPrefix段，但要注意append([]byte{}, ...)显式拷贝，否则多段共用底层数组
什么情况下不该用 Scanner 分片
只要出现以下任一条件，就该放弃 Scanner，改用 bufio.Reader 或裸 io.Read()：
- 文件不含换行符（如 protobuf 日志、HTTP body dump、加密 blob）
- 需要保留原始换行符（
\r\n或\r）或自定义分隔符（如\x00） - 要精确控制每块读取字节数（例如 1MB 块对齐上传）
- 分片逻辑需与 mmap、零拷贝或异步 I/O 集成
分片最难的不是读多少字节，而是“在哪断”和“怎么缝”。行边界对齐漏掉一个 Seek 或少拼一次末尾，结果就是整批数据语义错乱——这种问题在线上日志归档或离线数仓导入里，往往要跑完才发现，没法重来。
