mmap比os.open+bufio.scanner快得多，因mmap将文件直接映射进虚拟内存，跳过内核到用户态的数据拷贝；而scanner需高频系统调用、内存分配及字符串解析，gb级日志下性能灾难。
为什么 mmap 比 os.Open + bufio.Scanner 快得多
因为 mmap 把文件直接映射进虚拟内存，跳过了内核态到用户态的数据拷贝；而 bufio.Scanner 每次读一行都要系统调用 + 内存分配 + 字符串解析，对 GB 级日志就是灾难。尤其当你要随机查找某时间戳或某请求 ID 时，mmap 配合二分或索引结构才能真正“极速”。
如何用 syscall.Mmap 正确打开只读大文件
Go 标准库没有封装 mmap，得靠 syscall.Mmap。注意三点：文件必须先 os.Open 获取 *os.File，再用 fd := file.Fd() 拿句柄；长度要提前知道（file.Stat().Size()）；flag 传 syscall.PROT_READ 和 syscall.MAP_PRIVATE ——别用 MAP_SHARED，写日志文件会崩。
- Windows 上要用
syscall.VirtualAlloc+syscall.CreateFileMapping，不是同一套 API - 映射后得到的
[]byte是可直接下标访问的，但不能 append 或扩容 —— 它背后是虚拟内存页，越界 panic 是 SIGBUS，不是 slice panic - 记得在 defer 里调用
syscall.Munmap，否则内存泄漏（Linux 下不释放，进程退出才回收）
用 unsafe.Pointer 转换 mmap 数据为结构体指针的危险操作
日志如果是固定格式（比如每行 128 字节、字段偏移确定），可以用 unsafe.Pointer 把 mmap 得到的字节切片头地址转成结构体指针数组，避免逐行解析。但必须确保：
- 结构体用
//go:packed且字段顺序与日志二进制布局完全一致 - 所有字段类型宽度确定：
int64而非int，[32]byte而非string - 绝对不要对转换后的指针做
reflect.ValueOf().Interface()—— 这会触发逃逸和复制，瞬间毁掉 mmap 的优势 - 示例：假设日志是
ts int64; reqid [16]byte; status uint32，可用(*LogEntry)(unsafe.Pointer(&data[0]))直接取首条
检索时别直接遍历 mmap 内存块
哪怕用了 mmap，线性扫描 10GB 文件仍是 O(n)。真正提速靠预建索引：比如把每 1MB 块的第一个时间戳记下来，做成 []int64 数组，再二分定位目标块；或者用内存中构建 map[string][]uint64 存 request_id → 日志偏移列表（偏移用 uint64，因为文件可能 >4GB）。索引本身可以序列化到磁盘，启动时 mmap 加载，比每次重建快得多。
最容易被忽略的是：mmap 映射区域的 page fault 开销。如果随机跳着访问（比如按 hash 查 request_id），CPU cache miss + 缺页中断反而比顺序读慢 —— 所以索引设计必须尽量局部化，让一次检索尽量落在相邻几个内存页内。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
