os.Open本身可打开GB文件，但直接配合默认bufio.Scanner会因64KB缓冲上限遇超长行报bufio.ErrTooLong；真正瓶颈是高频syscall和内存拷贝，应改用bufio.NewReader配大缓冲（如1MB）并手动按\n/\r\n切分，或用mmap跳过拷贝加速只读查找。
为什么 os.Open 不能直接用于 GB 级文件的逐行扫描
因为默认 bufio.Scanner 的缓冲区上限是 64KB，遇到超长行（比如日志中嵌入的 base64 或 JSON blob）会直接报错 bufio.Scanner: token too long；更关键的是，逐行读取本身在大文件场景下不是瓶颈，真正拖慢的是频繁系统调用和内存拷贝。你得绕过 Scanner，改用 bufio.NewReader 配合手动切分逻辑。
- 用
reader.Read(p []byte)批量读取，每次处理 1MB 左右的 chunk，减少 syscall 次数 - 行边界判断必须自己实现：扫描
\n或\r\n，注意跨 chunk 边界的换行符不能被截断 - 避免把整行内容拼成新字符串——用
bytes.IndexByte定位起止偏移，直接切片原 buffer 引用
如何用 mmap 在 Go 中加速只读查找
Go 标准库不支持 mmap，但 golang.org/x/sys/unix 提供了跨平台封装。对只读、顺序扫描型查找（如 grep 类任务），mmap 可省去 read() 的数据拷贝，内核直接映射文件页到进程地址空间。实测 5GB 日志文件，mmap 比传统 read 快 1.8 倍左右（SSD 环境）。
- Windows 下需用
golang.org/x/sys/windows的CreateFileMapping+MapViewOfFile - Linux/macOS 用
unix.Mmap，注意传入unix.PROT_READ和unix.MAP_PRIVATE - 映射后得到一个
[]byte，可直接用bytes.Index或bytes.Contains查找，但别用strings包——它会强制 UTF-8 解码，遇到二进制内容就 panic
bytes.Index 和 bytes.IndexRune 的实际性能差异在哪
查 ASCII 字符串（如 HTTP 状态码 "200" 或字段名 "user_id:"）时，bytes.Index 是纯字节匹配，O(n) 且无额外开销；而 bytes.IndexRune 会按 UTF-8 规则解码每个 rune，哪怕你只找 ASCII 字符也多出解码成本。实测在 1GB 文件中搜 "ERROR"，前者耗时 120ms，后者 310ms。
- 只要目标字符串不含 Unicode 多字节字符，一律用
bytes.Index - 如果要支持 Unicode 模式匹配（如中文关键词），改用
regexp，但提前编译regexp.MustCompile，别在循环里反复Compile - 对固定前缀查找（如日志开头的
"[INFO]"），可用bytes.HasPrefix，比Index更快
并发分块查找时怎么避免重复命中同一行
把大文件按字节范围切分成 N 份并发处理，最易出错的是行被切在中间——比如第 1 块末尾是 "user=alice"，第 2 块开头是 "\nlevel=info"，两块各自查 "alice" 都会命中，但其实是同一行。解决方法不是加锁，而是让每块多读几个字节做“重叠缓冲”。
立即学习“go语言免费学习笔记（深入）”；
- 每块起始位置往前回退，找到最近的换行符（用
bytes.LastIndexByte），确保从完整行开头开始 - 每块结尾往后多读最多 1024 字节，直到遇到下一个换行符再截断，保证最后一行完整
- 主 goroutine 启动前先用
os.Stat获取文件大小，计算每块大致字节长度，避免Seek调用（随机 IO 慢）
真正的难点不在算法，而在边界处理——文件末尾没换行符、空行、超长行、混合换行符（CRLF/LF 混用），这些情况不覆盖全，结果就不可靠。
