bufio.Scanner行边界断裂主因是手动Seek破坏其内部缓冲状态；应改用bufio.Reader+ReadBytes('\n')手动定位，或预设scanner.Buffer避免超长行截断。
bufio.Scanner 读大文本时行边界断裂怎么办
用 bufio.Scanner 按行处理日志或 CSV 等文本文件时，如果文件被并发分段读取或手动 Seek 后再 Scan，极大概率出现「一行被切在两个 buffer 中」，导致 scanner.Text() 返回不完整内容甚至丢数据。
根本原因是 Scanner 内部维护自己的缓冲区和状态机，不感知外部文件指针偏移；一旦你调用 file.Seek() 跳转位置，Scanner 的内部 buffer 就彻底失效。
- 不要对已包装
Scanner的*os.File手动Seek - 若需跳转到某行（比如构建索引后定位），改用
bufio.Reader+ 手动换行查找：先file.Seek()，再用reader.ReadBytes('\n')或逐字节扫描 - 若必须用
Scanner，且单行可能超长，务必提前调用scanner.Buffer(make([]byte, 64*1024), 1 扩容，否则遇到超长行直接报token too long
如何用 mmap 实现只读型多级索引
对固定格式的大文件（如结构化日志、TSV、自定义二进制块），用 mmap 构建内存映射后，可直接按偏移随机访问任意记录，避免反复 read() 和系统调用开销——这是实现「多级索引」最轻量的底层支撑。
Go 标准库不带 mmap，但 github.com/edsrzf/mmap-go 在 Linux/macOS/Windows 上都稳定可用。关键点不是“能不能映射”，而是“怎么组织索引结构”：
- 一级索引：文件头存一个
uint64数组，每个元素是第 N 条记录在文件中的起始偏移（适合定长记录） - 二级索引：对变长记录，额外维护一个稀疏索引文件，每 1000 行存一次偏移 + 行号，查询时先二分查稀疏索引，再从该位置线性扫描到目标行
-
mmap映射后，索引数组本身可直接用unsafe.Slice()转为[]uint64，无需拷贝 - 注意：
mmap不触发 page fault 就不占物理内存，但len(mmapSlice) == 文件大小，别误以为它“加载了全部内容”
并发分段读 + 偏移映射表 = 可定位的流式处理
当你要支持「快速跳转到第 100 万行」且文件还在持续写入（如实时日志归档），不能依赖静态 mmap 或全量索引。这时真正的多级能力来自运行时构建的「偏移映射表」+ 并发分段读取。
核心思路是：把文件逻辑切分成固定大小块（如 1MB），每个块开头强制对齐到完整行，并记录该块首行号与文件偏移。这样索引表体积小、构建快、支持追加：
- 启动时用单协程顺序扫描一遍文件，每遇到换行符就记录当前
file.Seek(0, io.SeekCurrent)值，每满 10000 行存一条索引项到内存 map 或 LevelDB 中 - 查询第 N 行时，先查索引表找到所属块，再打开文件
Seek到该块起始偏移，用bufio.Reader逐行读取直到目标行 - 写入新内容时，只追加索引项，不重写原索引文件；旧索引可定期 compact
- 别用
io.Copy直接复制整个块——它不识别行边界，会导致后续块首行被截断
为什么 os.ReadFile 和 ioutil.ReadAll 绝对不能用于多级索引场景
这两个函数本质是封装了 os.Open → os.Stat → make([]byte, size) → file.Read()，它假设你能把整个文件塞进内存。对 GB 级文件，这不仅 OOM 风险高，更致命的是：它们返回的是独立内存副本，和原始文件磁盘位置完全脱钩——你根本拿不到任何「偏移量」信息，所有基于位置的索引、跳转、范围查询都无从谈起。
哪怕只是想“读取最后 100 行”，也必须用 os.File.Stat() 获取 Size()，再用 file.Seek() 反向查找换行符。这个过程天然要求你持有 *os.File 句柄，而不是一个孤立的 []byte。
所以只要需求里带「定位」「跳转」「范围」「末尾」「某一行」这些词，第一步就必须放弃 os.ReadFile，从 os.Open 开始控制文件句柄生命周期。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
