syscall.mmap能绕过read()的内核拷贝，因其将用户空间虚拟内存直接映射到文件物理页，省去page cache到用户buffer的数据拷贝；但缺页时仍触发磁盘i/o，非零成本读取。
syscall.Mmap 为什么能绕过 read() 的内核拷贝
因为 syscall.Mmap 让用户空间虚拟内存直接映射到文件的物理页，内核不再需要把数据从 page cache 拷贝到用户 buffer——read() 调用时这一步是必须的。但注意：这只是“避免拷贝”，不是“避免访问磁盘”；缺页时仍会触发 page fault 和磁盘 I/O。
典型误用是以为 mmap 后就能零成本读取整个文件。实际上，首次访问每一页都会触发缺页中断，如果文件远大于物理内存，频繁换页反而比 read() + 大 buffer 更慢。
- 适用场景：随机访问大文件中的少量区域（如数据库索引）、只读且需多次遍历、或配合
MADV_RANDOM/MADV_SEQUENTIAL提示内核预读策略 - 不适用场景：一次性顺序流式读取 TB 级日志（此时
read()+ 1MB buffer 更稳） - 关键限制：映射长度不能超过进程虚拟地址空间剩余量（64 位通常够，但碎片化严重时可能失败）
调用 syscall.Mmap 的最小安全写法
Go 标准库不封装 syscall.Mmap，必须手动调用底层系统调用，且需严格配对 syscall.Munmap。常见错误是忘记 defer syscall.Munmap() 或在 panic 路径中泄漏映射。
以下是最简可用模板（仅 Linux，其他平台需适配 syscall.SYS_MMAP 常量）：
fd, _ := os.Open("/huge/file")
defer fd.Close()
stat, _ := fd.Stat()
size := stat.Size()
data, err := syscall.Mmap(int(fd.Fd()), 0, int(size),
syscall.PROT_READ, syscall.MAP_SHARED)
if err != nil {
log.Fatal(err) // 注意：err 是 syscall.Errno，不是 *os.PathError
}
defer syscall.Munmap(data) // 必须在所有 return 前调用
// data 是 []byte，可直接索引访问，但越界 panic 不是 segfault，而是 Go runtime panic
-
syscall.PROT_READ足够用于只读；若需写入并同步回文件，改用PROT_READ|PROT_WRITE+MAP_SHARED - 偏移量必须是页对齐（
syscall.Getpagesize()），否则syscall.Mmap返回EINVAL - 映射长度也建议页对齐，否则末尾不足一页的部分行为未定义
映射后访问越界或 SIGBUS 的真实原因
Go 中对 syscall.Mmap 返回的 []byte 切片做越界访问，不会像 C 那样触发 SIGBUS，而是由 Go runtime 捕获并转为 panic（runtime error: index out of range）。但这只是表象——真正 SIGBUS 发生在两种情况：
- 访问范围超出文件当前长度（例如文件被截断，而映射未更新）
- 使用
MAP_PRIVATE且尝试写入时发生 COW 失败（如内存不足） - 映射时用了
syscall.PROT_WRITE，但文件以只读打开（open(O_RDONLY)）
调试 SIGBUS 的最有效方式是 strace -e trace=mmap,munmap,write,read 观察系统调用返回值，而非依赖 Go 层 panic 信息。
与 mmap(2) 原生行为的关键差异点
Go 的 syscall.Mmap 是对 libc mmap(2) 的直通封装，但有三个易忽略的差异：
- 返回值类型是
[]byte，底层数据头包含映射起始地址和长度，但 Go 不保证该 slice 可被unsafe.Slice任意扩展——它只是视图，不是独立内存块 - 不能用
unsafe.Pointer直接转成结构体指针再解引用（除非确保对齐和大小完全匹配），否则可能触发 GC 扫描异常或内存越界 -
syscall.Munmap后，原 slice 仍可被变量持有，但访问会触发 SIGSEGV（Linux）或 SIGBUS（macOS），Go runtime 不拦截这类信号
真正安全的用法是：映射 → 读/写 → syscall.Munmap → 立即丢弃对该 slice 的所有引用。任何跨 Munmap 的引用都属于未定义行为。
