因为bufio.scanner自动丢弃换行符且内部缓冲不可见，无法获取每行真实起始偏移；超长行会触发“token too long”错误导致索引构建失败；正确做法是用os.file.read配合手动换行符识别（优先\r\n、再\n、兼容孤立\r），逐块扫描并记录行首offset。
为什么不能直接用 bufio.Scanner 做行偏移索引？
因为 bufio.Scanner 会自动丢弃换行符、且内部缓冲区不可见，你根本拿不到每行在文件中的真实起始偏移。更麻烦的是，遇到超长行（比如单行几 MB）时它会直接 panic: bufio.Scanner: token too long，完全没法用于构建可靠索引。
正确做法是绕过所有高层封装，用 os.File.Read 配合手动查找 \n 或 \r\n：
- 逐块读取（例如 64KB buffer），避免内存爆炸
- 记录每次
read返回的字节偏移，作为潜在行首位置 - 在 buffer 内部扫描换行符，把每个
\n前的位置（即该行起始 offset）存入索引 slice - 注意跨 buffer 边界的换行：比如 buffer 末尾是
\r，下一块开头是\n，得合并判断
如何处理 Windows 和 Unix 换行混用？
真实日志或用户上传文本常混用 \n 和 \r\n，只找 \n 会漏掉以 \r\n 结尾的行，导致索引错位。必须统一按“逻辑行结束”识别：
- 优先匹配
\r\n（2 字节），再 fallback 到\n - 遇到孤立
\r（后面不是\n）时，按单个\r当作行尾（兼容旧 Mac 文本） - 索引中存的是每行**第一个字节**的 offset，不是换行符位置 —— 所以找到
\n后，offset = 当前扫描位置 - 行长度，而行长度需回溯计算
简单示例：buffer 中 "abc\r\nxyz\n"，第一行 offset=0，第二行 offset=5（\r\n 占 2 字节，所以 xyz 从偏移 5 开始）。
mmap 能不能加速大文件行偏移构建？
能，但不推荐在 Go 里盲目用 mmap。Go 标准库没有 mmap 支持，得靠 golang.org/x/sys/unix.Mmap，带来三个实际问题：
- Windows 上要换用
syscall.VirtualAlloc，跨平台代码变复杂 -
mmap后仍得自己扫描换行符，没省多少事；反而因 page fault 导致首次访问慢 - 大文件 mmap 后 RSS 内存可能虚高（尤其稀疏文件），被监控系统误判为泄漏
实测：对 10GB 纯文本，纯 read+buffer 方式（64KB buffer）比 mmap 快 10%~15%，且内存峰值稳定在 1MB 内。真正瓶颈从来不是 I/O，而是换行符查找逻辑本身。
索引构建后怎么快速定位第 N 行？
构建好的索引是个递增的 []int64，存的是每行开头的字节 offset。查第 N 行（0-indexed）只需：
if n >= len(index) {
return 0, errors.New("line out of range")
}
offset := index[n]
但注意两个坑：
- 最后一行可能没换行符结尾，你的索引长度 == 行数，但文件末尾没
\n时，最后一行的 offset 是有效的，只是后续 read 会到 EOF - 如果要读取该行内容，别用
file.Seek(offset, io.SeekStart)后ReadString('\n')—— 这会多读一次 syscall。更稳的方式是：seek 到 offset，然后用固定 buffer 读，直到遇到\n或 EOF
真正的难点不在构建，而在索引持久化和内存映射加载 —— 如果程序重启后不想重扫，就得把 []int64 序列化成二进制文件，并确保加载时做 endian 校验和长度验证，否则一个损坏的索引会让整行读取全错位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
