mmap 比 read + bytes.index 更适合大文件搜索，因其按需映射、不全载内存、避免 oom；需注意平台差异、只读权限、长度校验、页面对齐及显式释放资源。
为什么 mmap 比 read + bytes.Index 更适合大文件搜索
直接读整个文件进内存会触发 OOM，尤其在 1GB+ 的二进制文件上；bytes.Index 要求完整加载切片，没法流式处理。而 mmap（通过 syscall.Mmap）让内核把文件按需映射进虚拟地址空间，实际只占用页表和少量物理内存，搜索时像操作普通字节数组一样快，且不复制数据。
注意：这不是“零拷贝”——搜索时仍要触碰页面触发缺页中断，但比一次性 malloc 几百 MB 安全得多。
- Linux/macOS 支持原生
syscall.Mmap；Windows 需用golang.org/x/sys/windows的CreateFileMapping+MapViewOfFile - 映射区域大小必须 ≤ 文件长度，否则
syscall.Mmap返回EINVAL - 映射后记得调用
syscall.Munmap，否则进程退出前不会释放映射（虽内核会回收，但可能影响调试）
如何用 syscall.Mmap 安全映射只读二进制文件
关键不是“怎么映射”，而是“怎么避免 panic 和权限错误”。syscall.Mmap 参数顺序容易记混，且 flags 和 prot 组合有平台差异：
data, err := syscall.Mmap(int(fd.Fd()), 0, int(stat.Size()),
syscall.PROT_READ, syscall.MAP_PRIVATE)
-
syscall.PROT_READ是必须的；加syscall.PROT_WRITE会导致写入直接修改文件（危险） -
syscall.MAP_PRIVATE表示修改不落盘，适合只读搜索；syscall.MAP_SHARED会同步到文件，慎用 - 第三个参数是 length，不是 offset —— 传错会 panic 或映射失败
- Windows 下不能用
syscall.Mmap，必须用golang.org/x/sys/windows替代，且需先CreateFile以GENERIC_READ打开
在 mmap 内存上高效搜索字节序列（非字符串）
二进制文件里没有 UTF-8 边界，不能用 strings.Index。得用 bytes.Index 或手写 Boyer-Moore，但要注意：映射内存是 []byte，可直接传给 bytes.Index，无需 copy。
示例：搜索 4 字节 magic number [0x7f, 0x45, 0x4c, 0x46]（ELF 头）
magic := []byte{0x7f, 0x45, 0x4c, 0x46}
pos := bytes.Index(data, magic)
if pos >= 0 {
fmt.Printf("found at offset %d\n", pos)
}
- 搜索结果
pos是相对于映射起点的偏移，等于文件内真实 offset（因从 0 开始映射） - 若需多处匹配，用
bytes.IndexByte找首字节再校验后续，比反复调bytes.Index快 2–3 倍 - 避免对整个 GB 级
data调bytes.LastIndex—— 它会从尾部遍历，最坏 O(n)，应分块搜索
跨平台 mmap 封装的坑：Windows 上的句柄泄漏与对齐要求
Go 标准库没提供跨平台 mmap，自己封装时最容易栽在 Windows 上：
- Windows 要求映射长度必须是系统页面大小（通常 4KB）的整数倍，不足需向上取整，否则
MapViewOfFile失败 -
CreateFileMapping返回的句柄必须显式CloseHandle，否则每搜索一个文件就泄漏一个句柄，几百次后进程被系统 kill - Linux 的
syscall.Mmap返回的[]byte可直接用；Windows 的MapViewOfFile返回的是uintptr，需用unsafe.Slice转成[]byte（Go 1.20+） - 别依赖
os.File.Stat().Size()当作映射长度——某些网络文件系统或设备文件返回 0，得用syscall.Seek(fd, 0, io.SeekEnd)获取真实长度
真正麻烦的从来不是“怎么搜”，而是“搜完要不要 munmap”、“Windows 句柄关没关”、“页面对齐算没算错”——这些细节漏掉一个，程序跑几天就崩。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
